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Abstract 

"  Xn  ALR-46  Computer  Graphics  System  (CGS)  for  the  Electronic  Warfare 
Division  Engineering  Branch  Laboratory  was  designed  and  implemented. 
The  system  is  composed  of  the  ALR-46  Radar  Warning  Receiver;  real  time 
hardware  monitor;  PDP  11/34  computer;  and  two  display  devices,  a 
Tektronix  model  4027  CRT  and  a  Digital  Equipment  Corporation  (DEC)  model 
VT-100  CRT.  The  ALR-46  test  engineers  at  the  Engineering  Branch 
Laboratory  were  interviewed;  their  functional  requirements  were 
translated  into  a  detailed  set  of  hardware  and  software  requirements. 
Structured  Analysis  Techniques  were  used  to  produce  a  structured 
specification  for  the  system  requirements.  Yourdon  and  Constantine’s 
Transform  and  Transaction  Analysis  techniques  were  used  to  develop 
module  structure  charts  for  the  software  design.  The  final  software 
design  phase  translated  the  module  structure  charts  into  Warnier-Orr 
(W/0)  diagrams.  These  were  translated  into  operational  software  using 
DEC  Pascal.  The  software  was  implemented  and  tested  using  a  top  down 
approach.  The  modules  and  data  structures  were  designed  to  allow 
additional  capabilities  to  be  added  to  CGS  with  miminum  impact  on  the 
current  system.^.  The  data  acquired  by  the  hardware  monitor  from  the 
ALR-46  is  passed  to  the  PDP  11/34  for  CGS  analysis.  This  information  is 
used  either  to  simulate  the  pilot’s  display  or  to  generate  a  critical 
parameter  display  describing  the  threats  being  processed  by  the  ALR-46. 
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The  Air  Force  supports  many  Electronic  Warfare  (EW)  systems.  The 
primary  function  of  these  systems  is  to  respond  to  enemy  action  or 
potential  enemy  action  (Ref  1:1-2).  The  support  responsibility  for  each 
EW  system  is  assigned  to  an  Air  Force  organization  based  on  the  type  of 
maintenance  support.  When  a  user  of  an  EW  system  requests  that  a  change 
be  made,  it  is  the  responsibility  of  the  supporting  organization  to 
implement  the  change  and  distribute  the  modified  system.  The  Electronic 
Warfare  Avionics  Integration  Support  Facility  (EWAISF)  at  Robins  AFB  is 
responsible  for  two  classes  of  very  sophisticated  systems.  Radar  Warning 
Receivers  (RWR)  and  Jammers.  The  time  required  to  implement  a  change  to 
either  class  of  system  is  critical  to  the  user  and  the  EWAISF.  The 
intent  of  this  effort  was  to  develop  and  implement  a  computer  graphics 
system  which  would  reduce  the  time  required  to  evaluate  and  implement  a 
system  change. 

Background 

The  primary  function  of  the  RWR  is  to  warn  the  pilot  of  an  enemy 
threat  (anything  that  jeopardizes  the  life  of  the  pilot  or  the 
successful  completion  of  the  mission).  The  pilot  must  take  whatever 
action  is  necessary.  The  primary  function  of  the  jammer  is  to  protect 
the  pilot  and  insure  the  success  of  the  mission  by  denying  critical 
aircraft  information  such  as  aircraft  heading,  speed,  position,  etc.,  to 


the  threat. 


The  early  EW  systems  were  built  using  all  hardware  components  (Ref 
1:2-6).  The  time  required  to  make  a  change  to  the  system  was  excessive. 
As  a  result,  computers  became  an  integral  part  of  EW  systems.  A  change 
to  the  system  could  be  made  by  changing  a  few  computer  statements. 
Unfortunately,  the  personnel  required  to  maintain  the  new,  computer 
controlled  EW  systems  required  a  knowledge  of  hardware,  software,  and 
electronic  warfare.  The  Electronic  Warfare  Division  at  Robins  AFB, 
Georgia  was  formed  to  provide  the  Air  Force  a  centralized  EW  support 
facility. 

The  personnel  assigned  to  the  EWAISF  provide  both  hardware  and 
software  support  for  Air  Force  Avionics  Electronic  Warfare  systems.  The 
ALR-46  system  is  the  most  widely  used  of  all  the  EW  system  supported  by 
the  EWAISF.  Two  of  the  larger  users  of  the  system  are  the  Strategic  Air 
Command  (SAC)  and  the  Tactical  Air  Command  (TAC).  The  ALR-46  was 
designed  specifically  to  display  the  type  and  position  of  enemy  threats. 
It  is  able  to  distinguish  between  different  types  of  enemy  threats  by 
measuring  specific  parameters  of  the  Radio  Frequency  (RF)  energy 
received  from  the  enemy  threats  and  comparing  the  measured  parameters  to 
intelligence  data  parameters.  If  the  parameters  matched  within  a  user 
defined  tolerance,  the  appropriate  threat  symbol  is  displayed  to  the 
pilot.  If  the  user  of  the  system  is  not  satisfied,  he  might  request  a 
change.  Some  of  the  reasons  that  can  cause  a  user  to  request  a  change 
to  the  system  are  as  follows: 

-  As  the  intelligence  community  increases  its  knowledge  of  enemy 
threats,  new  and  better  techniques  for  detecting  the  threats  are 
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formed.  The  ALR-46  system  has  to  be  modified  to  install  these  new 
techniques . 

-  As  is  true  with  any  computer  controlled  system,  logical  errors  in 
the  computer  program  do  exist.  When  an  error  is  found,  the  ALR-46 
must  be  modified. 

Because  of  the  vast  number  of  enemy  threats  that  exist,  no  one  EW 
system  is  able  to  recognize  every  type  of  enemy  threat.  When  a  user 
of  the  ALR-46  system  decides  their  system  should  recognize  a  new 
enemy  threat,  a  change  request  is  submitted  to  the  EWAISF. 

When  a  change  request  is  received  by  the  EWAISF  (Ref  20),  it  is 
reviewed  by  the  ALR-46  configuration  control  board  and  is  entered,  based 
on  priority,  into  the  list  of  modifications  for  the  ALR-46.  When  a 
request  for  modification  reaches  the  top  of  the  queue,  the  request  is 
assigned  to  an  engineer.  The  engineer  and  assistants  are  responsible 
for  making  whatever  changes  to  the  system  are  required  to  satisfy  the 
user’s  request.  After  the  changes  have  been  installed  and  tested,  the 
updated  system  is  forwarded  to  the  user.  The  final  phase  of  the  system 
update  was  to  summarize  all  of  the  documentation  generated  during  the 
change  process  such  as  (1)  who  requested  the  change,  (2)  why  was  it 
needed,  (3)  what  changes  to  the  system  were  required  to  implement  it, 
etc.  The  EWAISF  maintains  a  history  of  the  changes  made  to  each  EW 
system. 
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Environment: 

The  ALR-46  section  is  maintaining  their  system  on  a  10-15  year  old 
Integrated  Support  Station  (ISS).  Figure  1  depicts  the  current  ISS  that 
is  currently  used  during  the  installation  and  testing  of  an  ISS. 
Several  steps  are  executed  each  time  a  modification  is  made  to  the 
ALR-46  system. 

-  The  threat  parameters  are  manually  programmed  into  the  threat 
simulator. 

-  The  ALR-46  system  is  modified  to  meet  the  new  user  requirements. 
The  user  requirements  could  either  cause  a  change  in  the  flight 
program  (software)  or  system  hardware  or  both. 

-  Each  modified  portion  of  the  system  is  tested  followed  by  a  test  of 
the  entire  system.  If  the  modification  is  extensive,  the  system 
will  be  flight-tested  in  the  aircraft.  Otherwise,  the  system  will 
be  bench-tested  using  either  the  local  ISS  threat  simulator  or  the 
Electronic  Warfare  Open  Loop  Simulator  (EWOLS)  to  simulate  an  enemy 
threat  environment. 

Since  the  flight  processor  is  the  only  computer  available  to  the 
ALR-46  test  engineer,  it  has  to  be  used  to  acquire  and  analyze  data 
during  the  test  phase  of  a  modification.  Data  acquisition  and  analysis 
has  a  severe  impact  on  the  ALR-46  performance.  The  test  engineer  is 
limited  to  a  few  brief  "snapshots'*  of  the  system.  The  failure  rate  of 
the  current  ISS,  combined  with  its  limited  capability,  forced  the  EWAISF 
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I  ENEMY  I 

I  THREAT  I 
I  SIMULATOR  I 


I  FLIGHT  I 
>1  PROCESSOR  I 


I  CRT  |  |  FLOPPY  | 


Figure  1.  Current  ALR-46  ISS 


I  ADVANCED  |  |  FLIGHT  I  I  HARDWARE  |  !  I 

I  ENEMY  THREAT  j  — >j  PROCESSOR  |—  >|  MONITOR  |— >|  PDP  11/34  | 

I  SIMULATOR  II  II  II  I 


I  DISK  I  I  CRT  | 


Figure  2.  ALR-46  Advanced  ISS  (AISS) 
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j  to  replace  the  current  ALR-46  ISS's  with  four  advanced  ISS's  (Ref  figure 

i 

;  2.).  Each  Advanced  ISS  (AISS)  is  equiped  with  a  stand-alone  PDP  11/34 

i 

j  computer  that  can  be  used  to  automatically  program  the  advanced  enemy 

I 

‘  threat  simulator  and,  when  used  in  conjunction  with  the  hardware 

i 

J  monitor,  is  capable  of  analyzing  the  performance  of  the  AIR-46  system 

without  affecting  the  performance  of  the  flight  processor.  The  four 
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AISS's  will  have  access  to  a  common  data  base  located  on  the  PDP  11/70 
(Ref  figure  3.).  The  PDP  11/70  will  perform  tasks  either  too  large  or 
too  time-consuming  for  the  PDP  11/34's.  The  first  AISS  and  the  PDP 
11/70  was  delivered  to  the  EWAISF  in  July,  1981.  Because  of  constraints 
beyond  its  control,  the  EWAISF  was  unable  to  develope/purchase  all  of 
the  data  acquisition  and  analysis  programs  it  needed. 

Problem 

The  lack  of  a  means  of  analyzing  data  acquired  by  the  AISS  and 
reporting  the  results  of  the  analysis  to  the  user  severely  limits  the 
AISS's  capabilities.  The  only  new  capalitities  available  to  the  test 
engineer  are  as  follows: 

-  a  more  advanced,  computer  controlled  threat  simulator 

-  a  means  of  acquiring  data  from  the  flight  processor  in  real  time 
(hardware  monitor) 

-  a  more  convient  means  of  editing  and  assembling  the  flight  processor 
programs 

a  proposed  reduction  in  the  mean  time  between  failures  (MTBF) 

Even  though  the  above  capabilities  will  assist  the  test  engineer  when 
making  a  modification  to  the  ALR-46  system,  a  further  reduction  in  the 
time  to  test  the  system  could  be  realized  if  the  following  existed:  a 
closed  loop  test  system  in  which  a  known  set  of  threats  would  be 
simulated  by  the  advanced  threat  simulator  and  the  flight  processor 
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would  be  monitored  to  determine  which  threats  it  recognized.  The  list 
of  threats  that  were  simulated  would  be  compared  to  the  threats 
recognized  by  the  flight  processor.  The  system  could  generate,  for  the 
test  engineer,  a  list  which  contained  (1)  the  threats  that  were 
simulated,  (2)  the  threats  that  were  recognized,  and  (3)  the  threats 
that  should  have  been  displayed.  The  magnitude  of  this  test  system  is 
not  apparent  from  this  simple  description.  A  mode1  of  the  ALR-46  is 
required  to  automatically  produce  a  list  of  threats  that  should  have 
been  produced  with  a  given  combination  of  simulated  threats.  Modeling 
flaws  have  been  the  topic  of  many  discusions  at  the  EWAISF.  The  threat 
parameter  tolerances  that  would  be  used  to  define  whether  the  system  had 
“accurately"  recognized  the  threat  is  also  a  grey  area  among  personnel 
at  the  EWAISF.  For  example,  if  the  RF  value  programmed  into  the 
advanced  threat  simulator  was  1000.6  and  the  ALR-46  system  measured  the 
signal  at  985.3,  is  this  right  or  wrong?  Until  the  modeling  and 
tolerance  questions  are  resolved,  this  portion  of  the  test  system  can 
not  be  completed. 

Scope 


This  study  will  concentrate  on  the  analysis,  design,  and 
implementation  of  a  system  to  analyze  and  display  the  information 
captured  by  the  hardware  monitor.  Since  data  can  be  accessed  in  any 
order  by  the  OFP,  the  information  provided  by  the  hardware  monitor  may 
appear  to  be  a  series  of  binary  words  taken  randomly  from  the  ALR-46 
central  processing  unit's  (CPU)  memory.  The  information  generated  by 
analyzing  the  data  taken  from  the  ALR-46's  memory  will  be  presented  to 
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the  operator  in  two  forms;  (1)  a  color  reproduction  of  the  pilot's 
display  using  a  Tekronix  4027  CRT.  The  color  will  be  utilized  to 
distinguish  between  two  or  more  threats  of  the  same  type,  when  being 
displayed  simultaneously  (2)  a  display  of  all  of  the  information  the 
ALR-46  system  has  acquired  on  each  enemy  threat.  The  completed  system 
will  be  delivered  to  the  sponsor  (EWAISF)  with  a  recommendation  on 
whether  or  not  the  benefits  of  a  color  graphics  CRT  justify  the 
additional  expenditure  on  future  AISS's. 

Summary  of  Current  Knowledge 

The  VAX-11/780,  Tektronix  4027  CRT,  and  the  DEC  VT-100  are 
essential  components  in  this  research  and  the  only  knowledge  of  any  of 
these  systems  comes  from  the  vendor  supplied  manuals.  For  the 
VAX-11/780,  this  consist  of  a  series  of  system  manuals,  the  Pascal 
manuals  (Refs  2  and  3),  and  DEC's  VAX-11/780  book  (Ref  4).  The 
documentation  on  the  Tektronix  4027  consist  of  an  operator's  manaul  (Ref 
5)  and  a  programmers  reference  manual  (Ref  6).  The  documentation  on  the 
VT-100  consist  of  a  user's  manual  (Ref  7). 

Approach 

A  complete  system  specification  for  the  ALR-46  Computer  Graphics 
System  was  developed.  A  "top  down"  and  "structured"  approach  (Ref 
8:279)  was  selected  for  the  analysis  and  design  of  the  graphics  system. 
A  top  down  strategy  allowed  the  design  to  first  address  those  levels 
closest  to  the  user  and  thereby  insure  that  the  design  was  consistent 
with  the  user '8  requirements.  Each  lower  level  reveals  more  and  more 
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details  about  the  system.  Data  Flow  Diagrams  (DFD's)  were  used  as  an 
aid  in  the  design  phase  of  the  system. 

The  first  phase  of  the  investigation  consisted  primary  of 
researching  the  literature  on  similar  systems  to  gain  a  better  working 
knowledge.  Exhaustive  searches  of  American  Computing  Machine  (ACM) , 
Digital  Equipment  Corporation  User  Society  (DECUS),  Industrial 
Electronic  Engineers  (IEE),  Defense  Technical  Information  Center  (DTIC), 
AFIT  Theses,  Avionics  System  Division  (ASD),  Avionics  Labs,  and  the 
EWAISF  failed  to  produce  a  similar  system.  The  research  did  provide 
information  on  man  /  machine  interfaces. 

Next,  six  ALR-46  engineers  were  interviewed.  From  these 
interviews,  a  set  of  functional  requirements  were  compiled  and  these 
were  used  to  help  derive  the  system  requirements  for  the  ALR-46  Computer 
Graphics  System  (CGS),  The  software  requirements  were  documented  using 
Structured  Analysis  (Ref.  8).  The  structured  specifications  consisted 
of  a  series  of  data  flow  diagrams.  Yourdon  and  Constantine's  structured 
design  technique  (Ref.  17)  was  used  to  translate  the  structured 
specification  into  module  structure  charts.  The  final  phase  of  the  CGS 
design  was  to  generate  Warnier-Orr  (W/0)  diagrams  from  the  module 
structure  charts.  The  W/0  diagrams  were  used  to  develop  the  CGS 
software  in  DEC  Pascal  on  a  VAX-11/780.  A  top-down  approach  was  used  in 
the  implementation  and  validation  of  CGS. 


Thesis  Development 

The  development  of  this  thesis  followed  the  approach  that  was  taken 
in  the  investigation.  The  CGS  functional  requirements  were  analyzed  in 
Chapter  II.  This  chapter  translated  the  results  of  the  user  survey  into 
the  system  level  requirements.  Also  included  was  introductory 
information  on  the  ALR-46  system,  hardware  monitor,  Tektronix  4027  CRT, 
and  the  DEC  VT-100  CRT. 

Chapter  III  further  defined  the  CGS  requirements.  The  operator 
interface.  Parameter  capability  and  RWR  capability  were  each  described 
in  more  detail  along  with  the  selection  of  the  CGS  language.  Appendices 
A,  B,  and  C  provide  supporting  information  including  a  complete 
description  of  the  ALR-46  data  which  must  be  processed  by  CGS. 

Chapter  IV  refined  the  CGS  software  requirements  further  using 
Structured  Analysis  (Ref  8).  The  data  flow  diagrams  produced  with 
Structured  Analysis  were  translated  into  module  structure  charts  using 
Yourdon  and  Constantine’s  structured  design  technique  (Ref.  17).  A 
complete  set  of  module  structure  charts  for  CGS  is  contained  in  Appendix 
D. 


Chapter  V  described  the  implementation  and  testing  of  the  CGS.  In 
this  chapter,  the  factors  affecting  implementation  were  described,  as 
well  as  the  testing  techniques  employed.  The  Warnier-Orr  diagrams  and 
source  code  listings  are  in  Appendix  E  while  Appendix  F  contains  the  CGS 
data  dictionary.  The  test  data  is  contained  in  Appendix  G. 
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Finally,  Chapter  VI  summarized  this  investigation  and  gave 
recommendations  for  follow-on  research  efforts. 
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II. 


ALR-^6  CGS  Funtional  Requirements  and  System  Conf igurar.ion 


Intrgdu.cti.oa 

The  first  phase  of  any  system  development  is  to  define 
requirements.  The  development  of  the  CGS  functional  requirements  is 
described  in  this  chapter.  The  results  of  the  user  survey  are  described 
followed  by  a  description  of  the  requirements  and  constaints  developed 
from  the  results  of  the  survey.  In  the  next  section,  the  requirements 
and  constraints  are  defined  in  terms  of  an  actual  computer  system. 
Finally,  each  component  in  the  computer  system  is  discussed.  A  more 
detailed  analysis  of  the  CGS  software  requirements  can  be  found  in 
Chapter  III. 

tlaer  Survey 

The  requirements  of  the  ALR-46  CGS  had  to  be  further  defined  to 
insure  that  the  system  produced  would  meet  the  primary  goal  of  the 
EWAISF,  which  was  to  reduce  the  time  required  to  modify  the  ALR-46 
system.  The  following  personnel  assigned  to  the  ALR-46  were 
interviewed:  4  Electronic  engineers,  2  technicians,  1  unit  chief,  and  1 
section  chief.  The  survey  was  divided  into  three  major  sections. 

In  the  first  section,  the  users  were  asked  what  phase  of 
modification  to  the  ALR-46  was  the  most  time  consuming.  All  of  the 
users  overwhelmingly  agreed  that  the  test/debug  phase  was  the  most  time 
consuming. 
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In  the  second  section,  the  users  were  asked  to  describe  from  a 
hardware  and  operator  interface  point  of  view,  how  a  reduction  in 
test/debug  time  could  best  be  achieved.  The  requirements  identified  by 
the  users  are  described  in  the  next  section.  The  users  were  unable  to 
prioritize  the  requirements  because  each  requirement  was  considered 
essential  for  the  particular  type  of  testing  it  would  be  used  with. 
However,  all  of  the  users  did  agree  that  the  parameter  display 
capability  would  be  used  the  most  often. 

In  the  third  section,  the  users  were  asked  to  describe  their 
requirements  for  an  operator  interface.  The  requirements  identified  by 
the  users  are  described  in  the  next  section. 


System  Level  Requirements 

The  user  survey  results  and  the  author's  experience  were  used  to 
define  the  following  system  requirements: 

1 •  RWR  Display.  A  means  of  reproducing  the  RWR  display  in  real  time 
(the  information  being  displayed  on  the  simulated  RWR  display  can 
not  lag  the  actual  pilot's  RWR  display  by  more  than  two  second).  If 
two  threats  with  identical  symbols  are  displayed  simultaneously, 
each  symbol  will  be  assigned  a  different  color. 


I  AISS  | - >|  Hardware  Monitor  | - >|  Computer  I - >|  Display  Device  I 
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Table  1.  Critical  Emitter  Track  File  Entries 


ENTRY 

NUMBER  OF  CHARACTERS 

1  1. 

SYMBOL 

4 

1  2. 

TYPE 

4 

1  3. 

BANDS 

5 

1  4. 

PRI  OR  FRAME  PERIOD 

6 

1  5. 

PULSE  TRAIN  DESCRIPTOR 

4 

!  6. 

PRI  AVERAGE 

5 

1  7. 

DEVIATION 

5 

f  8. 

SPECIAL 

2 

1  9. 

POWER 

1 

1  10. 

POWER  ROUND 

1 

!  11. 

HIGH  BAND  SINE 

3 

I  12. 

HIGH  BAND  COSINE 

3 

1  13. 

CEPC 

1 

1  14. 

AGE  COUNT 

2 

1  15. 

C/D 

2 

1  16. 

PRIORITY 

2 

1  17. 

PRIORITY  POWER 

1 

!  18. 

PRIORITY  POWER  ROUND 

1 

I  19. 

AZIMUTH 

3 

1  20. 

LETHALITY  RING 

3 

1  21. 

M.L.  AGE 

1 

1  22. 

RECORD  NUMBER 

2 

2.  Parameter  Display  A  means  of  displaying  critical  threat  file 
parameters  (Ref  Table  1). 


I  AISS  I - >1  Harovare  Monitor  | - >|  Computer  I - >1  Display  Device  I 


3. 


Operator  Interface.  The  operator  interface  must  have  the 
following  capabilities!  (a)  It  must  have  a  beginner  and  an 
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"experienced"  mode  of  operation.  The  "beginner"  mode  uses  very 
descriptive  prompts  that  lead  the  inexperienced  operator  through  the 
prompting  session.  The  "experienced"  mode  uses  very  concise  prompts 
that  help  to  keep  the  experienced  user  from  becoming  bored  during 
the  prompting  session,  (b)  The  interface  must  be  very  forgiving  . 
That  is,  the  system  should  not  abort  if  the  user  makes  a  mistake,  it 
should  resume  at  the  appropriate  level,  (c)  The  terminology  used  in 
the  prompts  must  be  as  similar  as  possible  to  that  used  by  the  user 
at  the  present  time,  and  (d)  A  help  command  should  exist  at  each 
major  level  of  the  prompt  structure. 

4.  Operational  Environment.  Each  of  the  four  AISS’s  must  be  able  to 

operate  the  CGS  simultaneously. 

5.  Application  Environment.  The  CGS  must  operate  in  the  same 

environment  as  the  ALR-46  system  and  must  be  readily  available. 
Since  space  is  very  limited  in  the  ALR-46  test  environment,  the 
space  required  by  the  CGS  must  be  minimal. 

pgngtraiatg . on.  the.  ALR.-.46.  CCS. 

1.  Compatibility.  Another  requirement  for  the  ALR-46  CGS  was  that  it 
must  be  compatiable  with  DEC's  PDP-11  series  of  computers, 
specifically  the  PDP  11/34  and  the  PDP  11/70.  The  EWAISF  defined 
DEC  computers  as  the  standard  for  use  on  all  support  equipment. 

2.  Operational  Environment.  The  CGS  must  not  affect  the  operation  of 
the  ALR-46.  If  the  ALR-46  is  affected  by  the  operation  of  the  CGS, 
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the  results  of  the  test  being  performed  would  be  biased. 


3.  Cost .  Any  hardware  or  software  that  already  exist  could  be  used 
in  order  to  minimize  the  coat  of  the  CGS.  One  of  the  two  color 
graphics  terminals  (Chromatics  model  5001  and  the  Tektronix  model 
4027),  available  from  the  sponsor,  should  be  used  if  possible. 

4.  Programming  Language.  The  software  can  be  written  in  FORTRAN  or 
Pascal.  Both  languages  satisfy  the  standardization  requirements  of 
the  sponsor.  Assembly  lanuage  will  only  be  used  if  it  is  essential 
for  execution  speed. 

Meeting  the  Requirements. 

Introduction.  In  this  section,  t^e  hardware  requirements  defined 
in  the  previous  section  are  translated  into  a  physically  realizable 
system.  The  software  requirements,  including  the  operator  interface, 
are  discussed  in  Chapter  III.  The  first  step  in  translating 
requirements  into  a  physical  system  was  to  determine  what  new  equipment 
was  needed  by  comparing  the  requirements  and  the  available  hardware  (Ref 
figure  4).  This  made  it  apparent  that  a  PDP  11/34  computer,  a  hardware 
monitor,  and  a  DEC  VT100  CRT,  all  of  which  are  already  in  each  AISS, 
combined  with  the  Tektronix  4027  CRT,  would  satisfy  all  of  the  CGS 
hardware  requirements.  Even  though  the  Chromatics  5001  is  a  color 
graphics  terminal,  it  was  eliminated  from  consideration  because  it  does 
not  support  the  requirements  of  the  operator  interface.  It  does  not 
allow  the  screen  to  be  divided  into  regions.  The  PDP  11/70  was 
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AVAILABLE  HARDWARE 


REQUIREMENTS 


RWR  Display 
Parameter  Display 
Operational  Environment 
Application  Environment 
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Figure  4.  Sytems  Requirements  Verses  Available  Hardware 


eliminated  as  a  potential  host  for  CGS  because  it  did  not  satisfy  the 
real  time  constraints  of  the  first  two  requirements  (RWR  Display  and 
Parameter  Display) .  The  additional  time  required  to  move  the  data 
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acquired  by  the  hardware  monitor  from  the  PDP  11/34  to  the  PDP  11/70 
would  cause  an  excessive  time  delay  between  the  ALR-46  display  and  the 
CGS  display.  The  requirements/constraints  verses  the  CGS  hardware 
configuration  are  discussed  below: 

1.  RWR  Display.  The  Tektronix  4027  is  more  than  capable  of 

reproducing  the  RWR  display.  With  a  list  of  64  colors  to  choose 
from  (Ref  5),  the  operator  will  not  have  a  problem  distinguishing 
between  threat  symbols.  The  4027  was  selected  to  simulate  the 
pilot's  display  because  of  its  color  graphics  capabilities 
(described  in  a  later  section)  and  because  there  were  no 

expenditures  or  long  lead  times  since  the  sponsor  already  owned  it. 
The  hardware  monitor  will  be  used  to  acquire  the  data  from  the 
ALR-46,  and  the  PDP  11/34  will  be  used  to  host  the  software  needed 
to  analyze  the  data  supplied  by  the  hardware  monitor  and  to  drive 
the  Tektronix  4027  CRT. 

2.  Parameter  Display.  The  VT100  CRT  will  be  used  to  display  all  of 
the  critical  parameters  (Ref  Table  1)  the  operator  needs  during  the 
test/debug  phases  of  an  ALR-46  modification.  The  VT100  was  selected 
as  the  parameter  mode  display  device  because  of  its  cursor  control 
capabilities  (described  in  a  later  section)  and  because  there  were 
no  expenditures  or  long  lead  times  since  it  was  already  a  part  of 
the  AISS.  The  hardware  monitor  will  be  used  to  acquire  data  from 
the  ALR-46,  and  the  PDP  11/34  will  be  used  to  host  the  software 
needed  to  analyze  the  data  supplied  by  the  hardware  monitor  and  to 
drive  the  VT100  CRT. 
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3.  Operator  Interface.  Since  satisfying  the  requirements  of  the 
operator  interface  dealt  mostly  with  the  design  of  the  CGS  software 
package,  they  will  be  discussed  in  Chapter  III. 

4.  Operational  Environment.  Using  the  PDP  11/34's  and  the  VTlOO's  to 
host  the  CGS.  easily  satisfies  this  requirement,  except  when  two 
users  want  to  simultaneously  exercise  the  RWR  display  capability  of 
CGS.  There  is  no  immediate  solution  to  this  problem  since  the 
sponsor  only  has  one  Tektronix  4027.  The  hardware  monitor, 
discussed  in  a  later  section,  provides  CGS  with  a  means  of  acquiring 
the  data  it  needs  without  affecting  the  operation  of  the  ALR-46 . 

5.  Application  Environment.  Again,  using  the  PDP  11/34's  and  the 
VTlOO's  to  host  the  CGS  easily  satisfy  this  requirement,  since  these 
devices  are  already  an  integral  part  of  the  AISS.  The  Tektronix 
4027  will  be  easily  tranportable  to  the  required  AISS. 

6.  Computability .  The  PDP  11/34  and  VTlOO's  definitely  meet  the 
sponsors  compatibility  requirements.  They  are  already  an  integral 
part  of  the  ALR-46  AISS.  The  Tektronix  4027  CRT  is  also  fully 
compatible  with  DEC  fs  PDP-11  and  VAX  family  of  computers  (Ref  5). 

7.  Cost .  No  equipment,  in  addition  to  that  already  owned  by  the 
sponsor,  was  needed  to  build  the  CGS. 

8.  Prnyrnrmm'ng  T.anyuaye.  The  PDP  11/34  supports  both  Pascal  and 
FORTRAN.  The  selection  of  the  language  used  to  develop  CGS  is 
discussed  in  Chapter  III. 
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System  Component  Architecture. 

In  the  following  section,  the  ALR-46,  VT100  CRT,  Tektronix  4027, 
hardware  monitor,  threat  simulator,  POP  11/34,  PDP  11/70,  and  VAX-11/780 
will  be  described  followed  by  a  description  of  the  features  that  all 
three  computers  have  in  common.  This  section  will  not  only  provide  the 
reader  with  a  clearer  understanding  of  CGS,  but  will  also  emphasize  the 
compatibility  that  exist  between  the  three  computers.  This 
compatibility  made  it  possible  for  CGS  to  be  developed  on  the  VAX-11/780 
and  then  transfered  to  the  PDP  11/34. 

ALR-46  System.  This  section  discussed  the  ALR-46  system  and 
should  provide  a  general  idea  of  how  the  ALR-46  functions,  as  well  as  an 
idea  of  the  magnitude  of  the  problem  the  test  engineer  is  faced  with  in 
validating  the  system  after  a  modification  has  been  made.  But  for  a 
description  of  the  ALR-46  system  to  be  meaningful,  the  EW  environment 
the  ALR-46  operates  in  must  be  described. 

The  EW  Environment  consist  of  one  or  more  enemy  threats.  The 
threats  can  be  divided  into  classes  or  types.  The  ALR-46  uses  the 
characteristics  of  the  signals  that  each  threat  transmits  to  identify 
it.  The  threat  characteristics,  also  called  parameters,  are  defined 
below: 

A.  Pulse  —  used  to  gate  the  RF  energy  being  transmitted  by  the 
threat. 

B.  Pulse  Width  (PW)  —  the  length  of  time  the  RF  energy  is 
transmitted. 
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C.  Pulse  Repetition  Interval  (PRI)  —  the  time  between  pulses. 


D.  Scan  Pattern  —  the  transmitter  is  moved  back  and  forth  to  cover 
more  area.  This  movement  creates  a  specific  pattern  that  can  be 
identified  by  the  ALR-46  system. 

E.  Radio  Frequency  (RF)  --  each  threat  transmits  at  a  given  RF. 
The  EW  system  uses  this  to  aid  in  the  identification  of  the  threat. 

F.  Power  Level  --  the  amount  of  RF  energy  measured  at  the  ALR-46. 

When  the  energy  transmitted  by  the  threat  strikes  the  plane,  a  small 
portion  of  the  energy  is  reflected  back  to  the  enemy  threat  where  it  is 
received.  The  enemy  threat  analyzes  the  energy  reflected  back  from  the 
plane  vtarget)  to  determine  the  distance  between  the  threat  and  the 
aircraft  (range),  the  direction  of  the  aircraft  (azimuth),  altitude, 
speed,  etc.  The  ALR-46  system  on  the  plane  also  receives  the  RF  energy 
transmitted  from  the  threat. 

The  front  end  of  the  ALR-46  consist  of  four  receivers  (ports),  RF 
measurement  equipment,  and  a  series  of  analog  to  digital  converters 
(A/D’s).  The  four  receivers  perform  two  major  functions.  First  and 
foremost,  they  received  a  portion  of  the  RF  energy  transmitted  by  the 
enemy  threat.  Because  they  are  located  at  different  points  on  the  plane 
(normally  one  on  each  wing  tip,  one  on  the  front  and  one  on  the  tail  of 
the  plane),  they  can  be  used  by  the  ALR-46  system  to  define  the 
direction  of  the  threat  (azimuth)  relative  to  the  heading  of  the 
aircraft. 


22 


A  pulse  of  RF  energy  is  received  simultaneously  at  each  of  the  four 
receivers.  The  time  the  pulse  arrived  is  recorded,  the  power  level  of 
the  signal  at  each  receiver  is  also  measured  and  recorded,  and  the 
frequency  is  measured  and  recorded.  The  time  of  arrival  (TOA) , 
frequency,  and  power  levels  are  digitally  transmitted  to  the  ALR-46 
flight  processor. 

The  flight  processor  is  the  heart  of  the  ALR-46  system.  It 
controls  the  operation  of  the  entire  system.  It  is  responsible  for 
commanding  the  front  end  to  make  measurements,  analyzing  the  parameter 
data  returned  from  the  front  end,  and  displaying,  to  the  pilot,  the 
status  of  the  EW  environment.  The  software  in  the  processor  can  be 
divided  into  three  categories: 

(1)  Threat  identification  tables  —  The  threat  ID  tables  contain  a 
list  of  parameter  values  for  each  threat  the  ALR-46  system  is  able 
to  recognize. 

(2)  Emitter  Track  File  —  The  emitter  track  file  is  a  collection  of 
data  on  each  threat  the  ALR-46  system  has  identified.  Of  course, 
this  list  is  constantly  changing  because  new  threats  begin 
transmitting,  current  threats  shut  off,  and  more  information  is 
derived  about  each  threat  (PRI,  scan,  etc.).  The  list  is  sorted  by 
threat  priority  (the  highest  priority  threat  points  to  the  next 
higher  priority  threat,  etc.). 

(3)  The  Parameter  Algorithms  —  These  algorithms  perform  the  actual 
processing  done  by  the  system.  Separate  algorithms  are  used  to 
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calculate  PRI,  scan,  etc.  When  the  algorithm  calculates  a  threat 
parameter,  it  is  entered  into  the  emitter  track  file. 

When  an  emitter  track  file  entry,  such  as  range,  azimuth,  etc.  is 
changed,  the  appropriate  changes  have  to  be  made  to  the  pilot’s  display. 
For  example,  as  the  plane  flies  closer  to  a  threat,  the  symbol 
representing  that  threat  is  moved  closer  to  the  center  of  the  diplay 
(Ref  figure  5).  The  center  of  the  display  represents  the  aircraft’s 
position. 

Many  interim  test  are  performed  while  a  modification  to  the  ALR-46 
is  being  made.  The  pilot's  display  is  the  only  means  the  test  engineer 
has  of  determining  if  the  system  is  working  correctly  unless  the  flight 
processor  is  stopped  and  the  emitter  track  file  is  dumped  to  a  CRT.  In 
1981,  ALR-46  engineers  use  a  large  amount  of  time  analyzing  a  given 
enemy  threat  symbol  being  displayed  on  the  ALR-46  monitor.  Personnel  at 
the  EWAISF  feel  that  after  a  modification  has  been  made,  the  time 
required  to  test  the  ALR-46  system  can  be  reduced  through  the  use  of  a 
color  display  (Ref  figure  5)  or  if  critical  entries  of  the  emitter  track 
file  (Ref  Table  1)  were  available  in  realtime  (no  more  than  two  seconds 
delay  between  actual  events  and  the  event  being  displayed), 

DEC  VT1QQ  CRT.  The  VT100  CRT  serves  as  an  input  device  for 
operator  commands  to  the  computer  and  as  an  output  device  for  data  sent 
from  the  host  computer  to  the  operator.  Time  consuming  preventive 
maintenance  test  are  not  necessary  because  the  VT100  has  built  in 
diagnostics.  Each  time  the  VT100  is  turned  on,  the  advanced  video 
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Figure  5.  Pilot's  ALR-46  System  Display 
Note:  Each  symbol  displayed  more  than  once  is  assigned  a  unique  color 


memory,  nonvolatile  memory,  internal  memory,  and  keyboard  are  checked. 
Unlike  most  terminals,  the  VT100  does  not  use  switches  or  jumpers  to 
individually  turn  the  built-in  terminal  features  on  or  off  (Ref  7:8). 
Instead,  the  VT100  uses  a  nonvolatile  memory  which  always  remembers  what 
features  have  been  selected.  The  selection  and  storage  of  built-in 
terminal  features  is  performed  by  simply  pressing  the  "set-up”  key  and 
selecting  the  desired  features.  Some  of  the  features  that  can  be 


controlled  are  autorepeat,  light  or  dark  background,  margin  bell, 
keyclick,  baud  rate,  tab  stops,  etc. 

With  the  advanced  video  option,  the  VT100  can  display  up  to  24 
lines  of  132  characters  each.  The  VT100  can  highlight  any  character(s) 
on  the  screen  in  any  of  the  following  ways:  bold,  blink,  underline, 

reverse,  or  any  combination  of  these  (Ref  7:65). 

The  VT100  has  a  large  selection  of  programmable  features  that  can 
be  controlled  from  the  host  computer.  Some  of  the  features  applicable 
to  CGS  are  described  below: 

1.  Cursor  Position  Report  (CPR)  -  The  CPR  command  reports  the  active 
position  of  the  cursor  by  returning  its  line  and  column  number. 

2.  Cursor  Backward  (CUB)  -  The  CUB  command  moves  the  sursor  to  the  left 
the  number  of  spaces  requested. 

3.  Cursor  Down  (CUD)  -  The  CUD  command  moves  the  cursor  downward  the 
number  of  lines  specified  without  affecting  the  column  position. 

4.  Cursor  Forward  (CUF)  -  The  CUF  command  moves  the  cursor  to  the  right 
the  number  of  spaces  requested. 

5.  Cursor  Position  (CUP)  -  The  CUP  command  moves  the  cursor  to  the 
position  specified  independent  of  the  current  position  of  the 
cursor. 

6.  Cursor  Up  (CUU)  -  The  CUU  command  moves  the  cursor  up  the  number  of 
lines  specified  without  affecting  the  column  position. 
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7 .  Double  Height  Line  (DECDHL)  -  The  DECDHL  command  allows  the  user  to 
create  lines  of  text  that  are  twice  as  high  as  normal. 

8.  Double  Width  Line  (DECDWL)  -  The  DECDWL  command  allows  the  user  to 
create  lines  of  text  that  are  twice  as  wide  as  normal. 

9.  Set  Top  and  Bottom  Margins  (DECSTBM)  -  The  DECSTBM  command  is  used 
to  set  the  top  and  bottom  margins  which  define  the  scrolling  region. 
Part  of  the  screen  can  remain  stable  while  the  remainder  of  the 
screen  can  be  used  for  operator  input  and  output. 

10.  Character  Attributes  -  This  command  is  used  to  emphasize  a  character 
or  a  series  of  characters  by  turning  on  bold,  underscore,  blink 
reverse  video,  or  any  combination  of  these. 

All  of  the  VT100  features  described  make  it  an  excellent  choice  for 
use  in  the  ALR-46  CGS. 

Tektronix  4027  Color  Graphics  CRT.  The  4027  belongs  to  the  class 
of  machines  popularly  known  as  “smart  terminals".  Like  the  VT100  ,  the 
4027  is  used  to  carry  communications  between  the  operator  and  the  host 
computer.  In  addition,  the  4027  contains  its  own  microprocessor  and 
supporting  electronics  (Ref  7:1-1).  With  these  electronics,  the  4027 
responds  to  its  own  set  of  commands,  independently  of  the  host  computer. 
The  4027  is  not  intended  to  be  a  stand-alone  computing  system.  Rather, 
its  computing  ability  complements  that  of  the  host  computer,  enabling 
the  user  to  make  full  use  of  the  4027 's  information  display 
capabilities.  It  is  designed  especially  for  creating  color  graphic 
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displays  in  up  to  64  different  colors.  The  4027  consist  of  a  display 
unit  and  a  keyboard  attached  to  the  display  unit  by  a  thin  cable.  The 
display  unit  contains  a  13  inch  color  CRT  capable  of  displaying  34  lines 
of  80  column  text.  The  4027  display  memory  can  be  divided  into  two 
portions.  One  portion,  called  the  workspace,  serves  as  a  composition 
area  for  creating  color  graphics,  editing  text  files,  filling  out  forms, 
or  displaying  the  results  of  application  programs  (Ref  7 : 1  —  2 ) .  The 
monitor  portion  of  memory  stores  messages  to  and  from  the  computer. 
Each  time  the  4027  is  turned  on,  all  of  its  memory  is  checked  by 
internal  diagnostics.  Many  of  the  operating  parameters,  such  as  baud 
rate,  left  margin,  right  margin,  tab  stops,  parity,  etc.,  can  be  set 
from  the  keyboard  or  from  the  host  computer.  The  4027  has  a  large  host 
of  programmable  features  that  can  be  controlled  from  the  host  computer. 
Some  of  the  features  applicable  to  CGS  are  described  below: 

1.  Jump  Command  -  This  command  positions  the  cursor  to  the  row  and 
column  specified,  independent  of  the  cursor's  current  position. 

2.  Up  Command  -  This  command  moves  the  cursor  up  tne  number  of  lines 
specified. 

3.  Right  Command  -  This  command  moves  the  cursor  to  the  right  the 
number  of  columns  specified. 

4.  Left  Command  -  This  command  moves  the  cursor  to  the  left  the  number 
of  columns  specified. 

5.  Color  Command  -  This  command  is  used  to  designate  the  color  of 
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subsequent  graphics 


6.  Map  Command  -  The  Map  command  provides  a  selection  of  64  possible 
colors  of  which  eight  may  be  designated  at  any  one  time. 

7.  Circle  Command  (CIR)  -  The  CIR  command  is  used  to  create  circles, 
circle  sectors,  and  equilateral  polygons. 

8.  Graphic  Command  (GRA)  -  The  GRA  command  is  used  to  define  a  graphic 
region  that  will  later  be  used  to  display  graphics. 

9.  Vector  Command  (VEC)  -  The  VEC  command  is  used  to  draw  line  segments 
in  the  graphic  region. 

10.  Relative  Vector  Command  (RVE)  -  The  RVE  command  is  used  to  draw 

vectors  by  specifying  relative  coordinates.  A  line  is  drawn 
starting  at  the  last  graphic  cursor  position. 

11.  Polygon  command  (POL)  -  The  POL  command  is  used  to  draw  a  large 

number  of  colored  shapes  and  panels. 

12.  String  Command  (STR)  -  The  STR  command  is  used  to  write  text  into 
the  graphic  region. 

13.  Eraae  G  Command  (ERA  G)  -  The  ERA  G  command  is  used  to  erase  a 

graphic  region. 

14.  Wo  ’:space  Command  (WOR)  -  The  WOR  command  is  used  to  define  the  size 
of  the  workspace.  The  number  of  lines  not  defined  as  workspace  is 
used  by  the  monitor. 
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Table  2 


Address  Limits  Table 


Lower  Limit 

1 

Upper  Limit 

1 

Lower  Limit 

2 

Upper  Limit 

2 

Lower  Limit  n 

Upper  Limit  n 

All  of  the  functions  described  are  performed  by  the  4027 's  internal 
processor,  thus  enabling  the  host  processor  to  simultaneously  perform 
other  task.  The  only  problem  encountered  with  the  4027  is  that  it 
failed  three  times  in  a  four  month  period.  Tektronix  has  assured  the 
sponsor  the  problems  with  the  4027  have  been  resolved. 

Hardware  Monitor.  The  hardware  monitor  (HM)  is  an  interface 

between  the  ALR-46  and  the  PDP  11/34.  The  monitor  is  used  to  extract 
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data  from  the  ALR-46  in  real  time  (within  a  few  microseconds  of  when  it 
actually  occur ed)  and  transfer  it  to  the  PDP  11/34  without  affecting  the 
operation  of  the  ALR-46  (Ref  13:3-1).  Data  captured  by  the  hardware 
monitor  is  stored  in  the  RM's  2048  word  internal  storage  buffer  until 
the  monitor  can  gain  control  of  the  PDP  11/34's  unibus  (unibus  is 
described  below).  When  access  has  been  gained  to  the  unibus,  the  data 
is  transfered  by  direct  memory  access  (DMA) »  i.e.,  the  data  in  the  HM 
can  be  transfered  into  the  PDP  11/34's  memory  without  the  aid  of  the  PDP 
11/34's  central  processing  unit  (CPU).  The  DMA  process  is  sometimes 
called  ""cycle  stealing"’  because  the  HM  steals  cycles  from  the  CPU  (Ref 
4:224).  The  hardware  monitor  has  two  modes  of  operation.  In  the  first 
mode,  a  series  of  address  limits  (Ref  Table  2),  that  are  to  be 
monitored,  are  defined  by  the  user.  Each  time  an  address,  that  falls 
into  one  of  the  address  limits,  is  written  to,  the  address  and  its 
contents  are  saved  in  the  monitor's  storage  buffer  (Ref  13:4-40).  As 
soon  as  there  is  time,  the  monitor  transfers  the  data  in  the  storage 
buffer  to  the  PDP  11/34  (Ref  figure  6).  In  the  second  mode,  a  series  of 
event  addresses  (Ref  Table  3),  that  are  to  be  monitored,  are  defined  by 
the  user.  The  event  addresses  represents  addresses  of  parts  of  the 
ALR-46  operational  flight  program  (OFF).  The  program  counter  (PC)  is  a 
pointer  to  the  specific  part  of  the  OFP  being  executed.  Each  time  the 
contents  of  the  program  counter  matches  one  of  the  entries  in  the  event 
address  table  (Ref  Table  3),  the  contents  of  the  OFP's  program  counter 
and  the  contents  of  the  real  time  clock  (two  words)  are  temporary  saved 
in  the  monitor  storage  buffer  (Ref  13:4-40).  The  value  "‘177777*’  is  used 
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Figure  6.  Data  Capture  With  the  Hardware  Monitor 


as  a  marker  to  distinguish  between  the  PC  and  time  (Ref  fig  7).  As  soon 
as  there  is  time,  the  monitor  transfers  the  information  in  the  storage 
buffer  to  the  PDP  11/34  (Ref  figure  7). 

Both  hardware  monitor  modes  can  be  exercised  simultaneously  without 
affecting  the  operation  of  the  ALR-46  in  any  way.  The  HM’s  internal 
storage  buffer  would  look  similar  to  table  4  if  both  modes  were  engaged 
at  the  same  time. 
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Table  3 


Event  Address  Table 


Program  Counter  1 


Program  Counter  2 


Program  Counter  3 


Program  Counter  n-1 


Program  Counter  n-1 


Program  Counter  n 


Program  Counter  n 


Threat  Simulator.  The  AISS  threat  simulator  is  used  to  stimulate 
the  ALR-46 .  It  creates  an  EW  environment  where  the  ALR-46  can  not  tell 
the  difference  between  the  simulated  EW  environment  and  the  actual  EW 
environment. 
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Figure  7 .  Event  Capture  With  the  Hardware  Monitor 


PDP-11  Computer.  The  PDP-11  processors  are  a  family  based  on 
common  architecture.  Compatibility  is  inherent  in  design,  and  is 
reflected  in  the  software  and  in  the  peripheral  options  (Ref  9:1).  For 
example,  the  VT100  terminal  is  compatible  with  the  PDP  11/34,  PDP  11/70, 
and  the  VAX-11/780  processors.  The  RSX-11M  operating  system  is  also 
compatible  with  the  PDP  11/34  and  the  PDP  11/70.  The  compatibility  of 
the  PDP  11  and  VAX-11  processors  can  be  seen  in  Figure  8. 
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Table  4 


Hardware  Monitor  Internal  Storage  Buffer 


The 

comiiion: 

*"Unibu8~ 


Data 

Ram  Address 

Data 

Ram  Address 

PC 

177777 

Time  0 

Time  1 
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1  —  -  1 

1  1 
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1  Data 
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1  Data 
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PDP-11  processors  have  one  outstanding  characteristic  in 
they  all  process  data  on  a  data  bus  called  the  "Unibus".  The 
allows  communication  between  any  two  devices  on  the  bus.  It 
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Figure  8.  PDP-11  Processor  Compatibility 


consist  of  56  signal  lines,  to  which  all  devices,  including  the 
processor,  are  connected  in  parallel  (Ref  9: 11) (Ref  figure  9). 
Communication  between  any  two  devices  and  the  bus  is  in  a  master/slave 
relationship.  During  any  bus  operation,  the  bus  master  controls  the  bus 
when  communicating  with  another  device  on  the  bus.  When  two  or  more 
devices  try  to  control  the  bus  at  once,  a  priority  scheme  is  used  to 
decide  among  them.  The  bus  is  always  given  to  the  requesting  device 
with  the  highest  priority.  If  two  devices  of  equal  priority  request 
control  of  the  bus,  the  device  that  is  electrically  closer  to  the 
processor  is  given  control.  The  priority  arbitration  takes  place 
asynchronously,  in  parallel  with  data  transfer.  Every  device  on  the  bus 
®xcept  memory  is  capable  of  becoming  a  bus  master  (Ref  9:13). 
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Figure  9.  Unibus  Configuration 

The  unibus  architecture  and  the  priority  scheme  is  further  defined  in 
Figure  9. 

Another  feature  that  the  PDP  11/34  and  PDP  11/70  have  in  common  is 
the  RSX-11M  operating  system.  RSX-llM  is  a  small  to  moderate-sized 
real-time  multiprograming  system  that  can  be  generated  for  a  wide  range 
of  application  environments,  from  small,  dedicated  systems  to  large, 
multipurpose  real-time  application  and  program  development  systems. 
RSX-llM  makes  it  transparent  to  the  user  whether  the  PDP  11/34  or  the 
PDP  11/70  is  the  host  computer.  The  operating  system  is  sophisticated 
enough  to  simultaneously  support  many  users  with  little  reduction  in 
response  time  and  also  satisfy  the  critical  time  response  real-time 
programs  require.  Software  generated  under  the  RSX-llM  operating  system 
can  be  executed  on  the  VAX-11/780  in  the  “compatibility  mode  .  The 
“compatibility  mode"  allows  the  VAX-11/780  to  simulate  the  PDP-11. 
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Another  feature  in  common  between  the  PDP  11/34  and  the  PDP  11/70 
is  the  means  by  which  they  manage  their  memory.  A  16  bit  virtual 
address  provides  direct  access  to  28K  words  (K=1024)  of  main  memory.  A 
program  executed  on  the  PDP  11/34  and  11/70  processors  with  memory 
management  can  address  up  to  32  K  words  of  main  memory  by  mapping  all  of 
the  virtual  address  space  to  physical  memory  (Ref  9:147).  The  memory 
management  system  on  the  PDP  11/34  can  map  a  32  K  program  into  any  of 
the  124  K  words  of  main  memory.  The  memory  management  system  on  the  PDP 
11/70  allows  a  32  K  program  to  be  mapped  into  any  of  the  1920  K  of  main 
memory.  The  key  attributes  of  memory  management  are  (1)  it  extends 
memory  address  space  and  provides  protection  and  relocation  features  for 
multiuser  applications. 

PDP  11/34.  The  PDP  11/34  is  a  general  purpose  computer 
manufactured  by  the  Digital  Equipment  Corporation  for  multi-task  and 
dedicated  applications.  It  contains  hardware  multiply/divide 
instructions,  memory  management,  and  enhanced  data  paths,  and  control 
signals  for  the  addition  of  hardware  floating  point  and  cache  memory 
options  (Ref  9:181).  The  features  common  to  all  PDP  11/34  processors 
are  (Ref  9) 

1.  Self-test  diagnostics  routines  which  automatically  executed  every 
time  the  processor  is  powered  up. 

2.  An  operator  front  panel  with  built-in  CPU  console  emulator  allows 
control  from  any  ASCII  terminal  without  the  need  for  the 
conventional  front  panel  with  display  switches  and  lights. 
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3  .  Automatic  bootstrap  loader 

4.  Up  to  124  K  words  of  either  Core  or  MOS  memory 

5.  Memory  management 

The  options  available  for  the  PDP  11/34  processor  are  (Ref  9) 

1.  Integral  extended  instruction  set  that  provides  hardware  fixed-point 
arithmetic  in  double  precision  mode. 

2.  Hardware  floating  point  option  allow  ten  times  the  performance  of 
software  implementations  (Ref  9:182). 

3.  Cache  memory  option  mean  up  to  60  percent  system  performance 
improvement  (Ref  9:182). 

4.  RSX-11M  operating  system 

5.  A  host  of  compilers  and  assemblers  which  include  Pascal  and  FORTRAN. 

The  sponsor’s  PDP  11/34  configuration  is  shown  in  Figure  10. 

PDP  11/70.  The  PDP  11/70  is  designed  to  operate  in  large, 
sophisticated,  high-performance  systems.  The  central  processor  performs 
all  arithmetic  and  logical  operation  required  in  the  system.  Memory 
management  is  standard  with  the  PDP  11/70,  allowing  access  up  to  two 
million  words  of  memory  (Ref  9:277).  The  cache  contains  1024  words  of 
fast  memory  (Ref  9:301).  Optional  high-speed,  mass  storage  controllers 
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Figure  10.  Sponsor's  PDP  11/34  Configuration 


provide  dedicated  paths  to  high  performance  storage  devices  (Ref 
9:312-313).  The  PDP  11/70  supports  a  host  of  operating  systems  and 
compilers  including  the  RSX-llM  operating  system  and  the  Pascal 
compiler.  The  sponsors  PDP  11/70  configuration  is  shown  in  Figure  11. 


VAX-11/780 .  The  short  description  of  the  VAX  that  follows  is  not 
included  because  the  VAX  is  a  part  of  CGS,  but  because  it  is  the 
computer  that  will  be  used  to  develop  CGS. 


The  VAX-11/780  is  the  virtual  address  extension  of  the  PDP-11 
family  of  computers.  It  is  a  32  bit  system  that  uses  a  very  complex 
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Figure  11. 


Sponsor's  PDP  11/70  Configuration 


virtual  operating  system.  The  32  bit  word  size  allows  the  VAX  to  have 
up  to  two  gigawords  of  unique  address  space  (Ref  11:345).  and  the 
virtual  operating  system  removes  all  constaints  on  program  size  (Ref 
10:255).  Even  though  the  VAX  is  much  larger  than  the  PDP-11  processors 
in  both  size  and  capacity,  it  still  has  the  PDP-ll's  same  basic 
structure,  consisting  of  the  high  speed  memory,  the  CPU,  and  the  I/O 
system(Ref  10:5).  The  VAX  does  not  support  the  RSX-11M  operating  system 
directly,  but  it  does  provide  a  "compatiblily  mode"*  which  allow  the  VAX 
to  execute  programs  developed  on  the  PDP-11  computers  with  no 
modifications.  DEC  has  made  it  very  easy  to  develop  programs  on  the  VAX 
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I  VAX —11/7  80  Processor  with  768  Kwords  of  Memory  and  VMS  ver  2.3  0/ S | 


I LAI 20  Decwriter  |  |7  VT100  CRT's |  I  2  RK07  Disk  Drives 


Figure  12.  AFIT  VAX-11/780  Configuration 


that  will  later  be  executed  on  one  of  the  PDP-11  family  of  computers.  A 
detailed  description  of  the  VAX  can  be  found  in  references  10  and  11. 
The  configuration  of  the  AFIT  digital  engineering  Laboratory’s 
VAX-11/780  is  shown  in  Figure  12. 

Summary 

In  summary,  this  chapter  was  devoted  to  the  analysis  of  the  CGS 
requirements.  First,  the  results  of  the  user  survey  were  described 
followed  by  a  description  of  a  proposed  system  to  satisfy  the 
requirements  and  constraints.  Next,  the  hardware  components  of  this 
system  were  described.  The  major  components  in  the  system  are:  the 
ALR-46 ,  the  VT100  CRT,  the  Tektronix  4027  CRT,  the  hardware  monitor,  the 
threat  simulator,  the  PDP  11/34,  the  PDP  11/70,  and  the  VAX-11/780. 


The  constaints  imposed  by  the  sponsor  on  CGS  hardware  compatibility 
and  availibility  did  limit  the  hardware  that  could  be  used  in  CGS.  Even 
though  system  requirements  were  discussed  in  this  chapter,  the  primary 
emphasis  was  on  hardware  requirements.  The  software  requirements  for 
CGS  can  be  found  in  the  next  chapter. 
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Software  Requirements 


Introduction 

The  previous  chapter  described  the  CGS  hardware  requirements/design 
in  detail,  but  only  briefly  described  the  CGS  software  system 
requirements.  Thi-  chapter  further  defines  the  software  requirements  of 
CGS.  The  software  requirements  define  the  type  of  communications 
between  the  user  and  CGS,  as  well  as  the  output  capabilities  of  CGS. 
The  general  structure  of  CGS  is  described,  followed  by  a  description  of 
the  communications  link  between  the  user  and  CGS.  The  requirements  of 
both  the  Parameter  and  the  RWR  modes  of  operation  are  discussed. 
Finally,  the  language  characteristics  required  to  support  the 
operational  capabilities  of  CGS  are  described. 

Software  Overview 

The  CGS  can  be  divided  into  three  major  categories  :  (1)  Operator 
Interface,  (2)  Processing,  and  (3)  Output.  As  shown  in  Figure  13,  the 
user  is  directly  affected  by  only  two  of  the  three  categories  (operator 
interface  and  output).  The  operator  interface  provides  the  user  with  a 
means  of  communicating  with  CGS.  The  user  can  request  help  or  request 
one  of  CGS’s  display  processes  be  executed.  Even  though  the  operator 
interface  and  the  output  processes  used  the  same  device,  they  are 
separate  functions.  The  operator  interface  provides  the  user  with  a 
means  of  requestings  CGS  perform  specific  functions  while  the  output 
processes  provides  a  means  of  displaying  the  results  of  the  user’s 
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Figure  13 .  Man  /  ALR-46  CGS  Interface 
request.  For  example,  when  the  user  request  the  RWR  mode,  the  operator 
interface  receives  the  user  command  and  passes  it  to  the  processing 
function.  The  processing  function  generates  the  display  data  and  passes 
it  to  the  output  function,  which  displays  the  requested  information. 
The  user  is  concerned  only  with  whether  or  not  the  display  data  was 
generated,  not  with  how  the  processing  function  generated  the  display 
data.  However,  the  user  can  be  indirectly  affected  by  the  processing. 
For  example,  if  an  error  occurs  in  the  processing  phase,  the  user  would 
be  notified  via  the  operator  interface.  The  operator  interface  is  the 
only  means  of  communications  between  the  user  and  CGS. 

Operator  Interface 

This  section  describes  the  characteristics  of  a  model  operator 
interface.  The  operator  interface  is  the  user's  means  of  controlling 
the  system.  Unfortunately,  most  interfaces  are  not  very  efficient  at 
communicating  with  their  users  (Ref  12:19).  They  often  fail  to 
understand  what  their  users  want  them  to  do  and  then  in  turn,  are  unable 
to  explain  the  nature  of  the  misunderstanding  to  the  user.  Most 
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interactive  computer  systems  respond  only  to  commands  phrased  with  total 
accuracy  in  a  highly  restricted  artificial  language  designed 
specifically  for  that  system  (Ref  12).  If  the  user  fails  to  use  this 
language  or  makes  even  the  slightest  mistake,  an  error  message  is  issued 
followed  by  a  request  to  reenter  the  command.  This  is  in  strong 
contrast  to  communication  between  people,  which  is  conducted  through  a 
wide-ranging,  natural  language  and  is  conducted  despite  many  errors  in 
language  use.  If  a  speaker  or  writer  makes  a  syntactic  error,  his 
listener  or  reader  does  not  normally  fail  to  understand,  but  instead 
makes  the  obvious  correction.  The  inability  of  current  interactive 
systems  to  make  such  corrections  is  very  frustrating  for  their  human 
users . 

Among  other  contributors  to  the  man-machine  communication  barrier 
is  the  poor  performance  of  interactive  systems  in  keeping  track  of 
dialogue  context  and  using  it  to  resolve  elliptical  or  anaphoric 
references  people  often  use  for  economy  of  phrasing  (Ref  12:19).  Again, 
people,  but  not  computers,  are  adept  at  suspending  one  context 
temporily,  switching  conversation  to  a  different  context,  and  then 
popping  back  to  the  original  one  (Ref  12,15).  A  user  who  enters  an 
illegal  command  while  using  a  typical  operator  interface,  is  forced  to 
seek  help  and  then  reenter  the  entire  command.  The  error  may  have  been 
as  trivial  as  a  mispelled  word,  but  the  interface  does  not  care.  It  is 
very  unforgiving!  The  operator  may  have  several  errors  in  the  command, 
and  yet  the  interface  forces  each  error  to  be  resolved  one  at  a  time, 
since  it  stops  interpretting  the  command  when  it  encounters  an  error. 
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The  operator  is  not  only  forced  to  reenter  the  command  several  times* 
but  is  also  prone  to  making  new  errors  while  trying  to  correct  the  old 
ones.  Once  a  given  mode  (class  of  instructions  such  as  edit*  list 
directory*  etc.)has  been  selected*  the  operator  is  locked  in  (Ref 
15:90).  If  the  operator  needs  to  enter  another  mode  to  resolve  a 
problem  encountered  in  the  current  mode*  the  state  of  the  current  mode 
is  lost.  All  of  the  problems  described  above  can  make  an  operator's 
first  encounter  with  an  interactive  computer  system  very  frustrating. 
Most  of  the  problems  normally  encountered  with  an  operator  interface 
could  be  eliminated  if  the  interface  was  more  cooperative.  In  systems 
that  do  not  use  extremely  abbreviated  command  languages,  most  spelling 
and  syntax  errors  could  be  automatically  corrected  by  comparing  the 
command  entered  by  the  operator  with  the  list  of  legal  commands.  In 
this  way,  the  operator  is  only  required  to  reenter  the  command  when  it 
is  too  different  from  any  legal  command  to  be  recognized. 

Research  in  human  communication  needs  has  resulted  in  a  list  of 
characteristics  that  an  operator  interface  should  possess  (Ref  12): 

1.  Flexible  parsing.  Whenever  people  spontaneously  use  a  language, 
whether  natural  or  artificial,  they  make  many  small  mistakes  in 
syntax  and  spelling  and  frequently  do  not  say  exactly  what  they 
mean.  A  graceful  system  must  be  able  to  process  its  user's  input 
when  a  linguistic  error  is  made,  and  then  to  correct  the  mistakes  if 
possible,  or  ask  for  a  selection  between  alternative  interpretations 
of  what  was  said. 
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2.  Robust  communication.  A  graceful  system  must  be  able  to  let  its 
user  know  when  it  understands  and,  more  importantly,  when  it  does 
not.  While  avoiding  verbosity  or  an  unnecessary  disruption  of  the 
flow  of  conversation,  it  must  keep  the  user  informed  of  any 
assumptions  it  makes  about  what  was  said  and  allow  opportunities  to 
correct  any  misapprehensions  that  may  have  occured.  Conversly,  and 
much  more  difficult,  it  should  monitor  the  user’s  understanding  of 
its  output  and  try  to  correct  any  demonstrated  misunderstandings. 

3.  Identification  from  description.  A  fundamental  ability  of  any 

interface  is  that  of  recognizing  objects  known  to  it  internally  from 
a  user's  description  of  them.  A  graceful  interface  must  also  be 
able  to  negotiate  with  the  user  when  the  descriptions  turn  out  to  be 
ambiguous  or  when  they  have  no  referents.  The  interface  should  be 
able  to  do  this  without  losing  the  larger  context  in  which  the 
description  occured. 

4.  Focus  tracking.  A  graceful  system  should  be  able  to  track  the 
focus  of  attention  of  the  user  as  it  change  through  the  dialogue. 
It  should  be  able  to  track  it  both  within  restricted  contexts,  such 
as  occur  in  a  description  resolution,  and  across  leaps,  such  as 
those  that  typically  occur  between  separate  commands  to  the 
interface.  When  such  large  leaps  occur,  it  should  also  be  prepared 
to  follow  the  focus  back  to  the  original  context.  This  allows  the 
user  to  break  off  one  command,  execute  another,  and  go  back  to  the 
first.  Keeping  track  of  the  focus  is  important  in  the  resolution  of 
elliptical  and  anaphoric  inputs. 
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5.  Natural  output.  A  graceful  interface  should  be  able  to  produce 
output  appropriate  to  the  current  context,  with  the  correct  amount 
of  detail  in  the  object  descriptions  it  generates. 

6.  Explanation  facility.  A  gracefully  interacting  system  should  be 
able  to  give  explanations  of  both  a  static  and  dynamic  nature  to  its 
user.  Static  explanations  relate  to  what  the  system  can  and  cannot 
do  in  a  general  sense,  and  how  the  user  can  ask  the  system  to  do  a 
specific  task.  Dynamic  explanations  describe  what  the  system  is 
doing,  why  it  is  doing  it,  and  the  outcomes  of  past  events. 

7 .  Personalization.  A  graceful  interface  should  recognize  and  adjust 
to  the  idiosyncracies  and  preferences  of  its  user.  This  includes 
the  ability  to  spot  and  correct  recurring  typographical,  spelling, 
or  syntactic  errors.  It  should  also  maintain  a  model  of  the  user's 
level  of  experience  and  adjust  its  messages  and  explanations 
accordingly. 

Even  though  the  design  and  implemention  of  an  interactive  system  that 
fulfills  the  requirements  outlined  above  is  a  very  large  task,  systems 
such  as  Alto,  Perq,  Lisp  (Ref  12)  and  Small  Talk  (Ref  15)  prove  it  can 
be  done.  One  of  the  main  reasons  that  many  current  systems  perform  so 
poorly  is  that  the  implementors  were  unable  or  unwilling  to  expend  so 
much  effort  on  the  user  interface.  The  sponsor  (Robins  AFB)  of  this 
thesis  feels  the  same  as  most  system  developers.  The  sponsor  chose  to 
have  a  less  sophisticated  operator  interface  and  operational  software 
developed  verses  a  more  sophisticated  operator  interface  and  no 
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operational  software.  The  trade-off  between  a  sophisticated  operator 
and  operational  software  was  necessary  because  the  limited  time  allowed 
to  complete  the  thesis.  A  sophisticated  operator  interface  would  have 
taken  several  months  to  design  and  implement,  which  is  more  time  than  is 
allowed  to  complete  the  entire  thesis.  Of  course,  the  primary  function 
of  the  operator  interface  is  to  provide  the  user  with  the  Parameter  and 
RWR  modes.  They  are  discussed  in  the  following  sections. 

Parameter  Capability 

As  mentioned  in  Chapter  II,  the  Parameter  capability  provides  the 
users  with  a  means  of  monitoring  the  critical,  OFP  track  file  parameters 
(Ref  Table  2),  without  affecting  the  operation  of  the  ALR-46  system. 
The  functions  required  to  provide  the  user  with  this  capability  are 
described  below: 

1.  The  Parameter  display  must  be  protected  against  itself.  That  is, 
the  operator  /  computer  dialogue  must  be  kept  in  a  dedicated  area  of 
the  display  and  the  same  is  true  for  the  parameter  output.  The 
result?  of  either  of  these  outputs  infringing  on  the  area  of  the 
other  are  obviously  catastrophic. 

2.  During  the  Parameter  sequence,  the  critical  parameters  on  the  ALR-46 
system  display  (Ref  figure  14)  must  be  identified.  Of  course,  the 
length  of  the  names  used  on  the  actual  display  will  be  determined  by 
the  space  available. 
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BY  PRIORITY  |  Threat  1  Data . Threat  16  Data 

SYMBOL  |  :  : 

TYPE  |  :  s 

BANDS  I  :  : 

PRI  /  FRAME  PERIOD  I  :  : 

PDLSE  TRAIN  DESCRIPTION  I  :  : 

PRI  AVERAGE  I  :  : 

DEVIATION  !  s  : 

SPECIAL  I  :  : 

POWER  /PWR  ROUND  I  :  : 

HIGH  BAND  SINE  I  :  ; 

HIGH  BAND  COSINE  I  :  : 

CEPC  |  s  : 

HI  BAND  AGE  COUNT  I  :  : 

CD  BAND  AGE  COUNT  i  : 

PRIORITY  I  :  : 

PRIORITY  /  ROUND  i  :  : 

AZIMUTH  I  :  : 

LETHALITY  RING  I  :  : 

ML  AGE  I  :  : 

RECORD  NUMBER  I  Threat  1  Data  ......  Threat  16  Data 


OPERATOR  /  COMPUTER  DIALOGUE  REGION 


Figure  14.  Parameter  Mode  User  Display 


3.  Another  critical  function  in  the  Parameter  mode  is  the  generation 
and  maintenance  of  the  user's  display.  In  this  mode,  all  threat 
data  collected  by  the  hardware  monitor  is  decoded  and  displayed  for 
up  to  sixteen  threats  simultaneously.  Each  time  a  threat  parameter 
in  the  track  file  is  changed,  the  hardware  monitor  sends  a  copy  of 
the  data  to  CGS.  CGS  decodes  the  word  and  updates  the  critical 
parameters  of  the  appropriate  threat.  For  a  detailed  description  of 
the  data  collection  and  decoding  processes,  refer  to  the  **Parameter 
/  RWR  Data*’  section.  A  detail  description  of  the  critical 
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parameters  to  be  displayed  can  be  found  in  Appendix  A.  Another 
useful  function  provided  by  CGS  is  the  RWR  capability  described  in 
the  following  section. 

RWR  Capability 

As  mentioned  in  Chapter  II »  the  RWR  capability  provides  the  user 
with  a  means  of  simulating  the  RWR  display  in  color  as  well  as  providing 
range  and  azimuth  data.  The  functions  required  to  provide  the  user  with 
the  capability  are  as  follows: 

1.  As  with  the  Parameter  display,  the  RWR  display  must  be  protected 
against  itself.  That  is,  the  operator  /  computer  dialogue  must  be 
kept  in  a  dedicated  area  of  the  display  and  the  same  is  true  for  the 
graphics  output.  The  results  of  either  of  these  outputs  infringing 
on  the  area  of  the  other  is  also  extremely  detrimental. 

2.  During  the  RWR  sequence,  parts  of  the  pilot's  display  (Ref  figure 
15)  are  static,  which  means  it  only  has  to  be  drawn  once.  The 
static  parts  of  the  display  are: 

(a)  Range  rings.  The  display  has  three  concentric  circles  (rings) 
which  represent  distance.  For  example,  if  the  display  were 
defined  at  sixty  miles  maximum,  the  outside  ring  would  represent 
sixty  miles,  the  next  ring  would  represent  forty,  etc.  A  small 
dot,  which  represents  the  position  of  the  aircraft,  must  be 
placed  in  the  center  of  the  circles. 
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Figure  15.  Static  ALR-46  Display 


(b)  Azimuth  Indicators.  The  circles  are  divided  into  four  equal 
quadrants  by  a  vertical  and  horizontal  line.  The  two  lines 
intersect  in  the  center  of  the  circles  and  extend  to  the  outer 
most  circle.  The  upper  half  of  the  vertical  line  represents 
zero  degrees  azimuth.  The  azimuth  angle  increases  in  the 
counter-clockwise  direction.  Four  hash  marks  start  on  the 
outside  ring  and  extend  inward  toward  the  center  of  the  circles 


for  approximately  one-half  inch.  The  hash  marks  are  positioned 
at  azimuth  angles:  45,  135.  225.  and  315  degrees. 

3.  The  RWR  mode  user's  display  (Ref  figure  16)  must  be  generated  and 
maintained.  If  a  change  was  made  to  a  threat's  symbol,  range,  or 
azimuth  parameters,  it  must  be  incorporated  into  the  RWR  mode  user's 
display.  This  RWR  user's  display  is  divided  into  three  regions. 
Region  one,  the  operator  /  computer  dialogue  region,  is  used  to 
display  messages  from  the  computer  and  to  enter  user  commands  to  the 
CGS.  It  is  not  affected  by  a  threat  parameter  change.  Region  two 
is  used  to  display  a  limited  number  of  critical  threat  parameters. 
Specifically,  the  threat  symbol  code,  range,  and  azimuth.  This 
region  is  updated  each  time  the  threat's  symbol,  azimuth,  or  range 
changes.  The  pilot's  display  region,  or  region  three,  is  a  replica 
of  the  actual  pilot's  display  except  for  the  addition  of  color. 
When  a  threat  is  first  recognized  by  the  ALR-46  system,  its  symbol 
is  displayed  at  the  appropriate  location  (based  on  its  range  and 
azimuth)  using  a  unique  color.  Each  time  a  change  in  range  or 
azimuth  occurs,  the  threat  symbol  must  be  repositioned  accordingly. 
When  the  treat  is  no  longer  active,  its  symbol  is  removed  from  the 
screen.  If  the  threat's  range  extends  beyond  the  maximum  display 
range,  then  the  threat  symbol  is  not  displayed.  Of  course,  the 
integrity  of  the  display  is  entirely  dependent  on  the  ability  of  CGS 
to  decode  the  information  taken  from  the  OFP  by  the  hardware 
monitor.  The  decoding  process  is  described  in  the  following 
section. 
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EMITTER  NUMBER  SYMBOL  RANGE  AZIMUTH 


16 


SA2 

AAA 


20 

50 


310 

48 


SA8 


100 


165 


ALR-46  Pilot's  Display 
(Reference  Figure  4) 


(  REGION  ft  2) 


(REGION  #3) 


OPERATOR  /  COMPUTER  DIALOGUE  REGION  (REGION  ft  1) 
ALR-46  CGS> 


Figure  16  RWR  Mode  User's  Display 

note:  Region  3  is  not  drawn  to  scale. 


Parameter  /  KW R,  Data 

A  detailed  description  of  the  ALR-46  operation  flight  program's 
(OF?)  emitter  track  file  will  help  the  reader  understand  what  is 
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required  to  generate  the  data  needed  to  drive  the  Parameter  and  RWR 
modes  user's  display.  Actually*  the  emitter  track  file  is  not  a  file, 
but  a  buffer  within  the  OFP.  The  OFP,  which  resides  in  the  memory  of 


the  ALR-46  Flight  Processor,  maintains  a  set  of  pointers 
(f irst_available_record  and  f irst_emitter)  which  point  to  records  in  the 
track  file  (Ref  figure  17).  If  the  f irst_available_record  points  to 
itself,  it  means  no  records  are  available.  If  the  f irst_emitter  pointer 
points  to  itself,  it  means  no  emitters  are  active.  The  track  files  are 
divided  into  sixteen  records,  which  contain  sixteen  words  each.  As 
shown  in  Figure  17,  the  records  in  the  track  file  form  two  linked  lists, 
the  ’"Red_Link_List"  and  the  ’*Blue_Link_List".  The  Red_Link„_List  is 
composed  of  records  of  active  emitters  while  the  Blue_Link_List  contains 
all  of  the  records  that  are  available  for  use.  The 
f irst_emitter_pointer  is  the  beginning  of  the  RedJLinkJList .  It  points 
to  the  highest  priority  threat,  the  highest  priority  threat  points  to 
the  next  highest  priority  threat,  etc.,  until  the  lowest  priority  threat 
is  reached.  The  lowest  priority  threat  points  to  the 
f irst_emitter_pointer .  The  f irst_available_emitter  pointer  is  the 
beginning  of  the  Blue_Link_List .  It  points  to  the  first  available 
record,  the  first  available  record  points  to  the  next  available  record, 
etc.,  until  the  last  available  record  is  reached.  The  last  available 
record  points  to  the  f irst_available_emitter  pointer. 

When  an  enemy  threat  is  recognized  by  the  ALR-46,  it  is  assigned, 
based  on  the  threat's  priority,  a  record  in  the  track  file.  The 
pointers  have  to  be  updated  in  both  linked  lists,  since  an  available 
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Address 


Operational  Flight  Program 


First_Available_Record  |<- 


First_Emitter 


Pointer  to  Next  Track  File  Record 


Data  Word  15 


Pointer  to  Next  Track  File  Record 


Data  Word  till  5 


Pointer  to  Next  Track  File  Record 


Data  Word  t£l5 


Figure  17.  ALR-46  Emitter  Track  File 


note:  The  pointer  arrangement  shown  depicts  fifteen  used  records 
(active  emi?cers)and  one  available  record. 
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record  has  to  be  removed  from  the  ”Blue_Li-nk_List‘’  and  inserted  into  the 
"Red_Link_List".  As  the  ALR-46  system  collects  more  information  about  a 
threat  (PRI»  PW,  etc.),  the  OFP  updates  the  appropriate  word(s)  in  the 
record  associated  with  that  threat.  Each  time  a  word  in  the  emitter 
track  file  is  updated,  the  hardware  monitor  stores  the  contents  and  the 
address  of  the  updated  word.  The  information  needed  to  drive  the  RWR 
and  Parameter  displays  must  be  extracted  from  the  data  (Ref  Table  4) 
taken  from  the  ALR-46  Flight  Processor  by  the  hardware  monitor.  The 
hardware  monitor  data  will  be  in  a  sequential,  fixed  length  record  file. 
Each  record  will  contain  four  thousand  ,  sixteen  bit  words.  As  shown  in 
table  4,  the  hardware  monitor  data  will  be  either  time  data  (in  groups 
of  four  words)  or  threat  data  (in  groups  of  two  words).  The  definition 
of  the  bits  in  each  of  the  sixteen  words  of  a  track  file  record  is 
defined  in  Appendix  A.  The  threat  data  is  the  only  data  required  to 
drive  the  RWR  display.  Of  course,  the  information  on  the  display  is 
only  as  good  as  the  programs  that  drive  the  display.  The  integrity  of 
the  programs  that  drive  the  display  are  heavily  influenced  by  the 
language  they  are  written  in,  which  brings  us  to  the  topic  of  the  next 
section. 

Selection  of  the  CGS  Language 

The  sponsor  left  the  choice  of  whether  to  write  the  software  in 
Pascal  or  FORTRAN  up  to  the  author.  Pascal  was  chosen  as  the  CGS 
language  for  several  reasons: 

1.  One  of  the  major  software  problems  through-out  industry  and  the 
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government  today  is  the  high  coat  of  maintaining  software.  This 
cost  could  be  reduced  if  the  software  was  better  documented  and 
structured.  Pascal  is  a  structured  language  with  many  structured 
commands,  such  as  "while",  "repeat  until",  and  "if  then", etc. (Ref 
2).  A  structured  program  is  normally  easier  to  understand  and  thus 
easier  to  maintain. 

2.  Unlike  FORTRAN,  Pascal  does  not  limit  the  variable  names  to  six  or 
nine  characters  as  FORTRAN  does  (Ref  3).  More  meaningful  variable 
names  make  the  program  more  readable  and  easier  to  understand. 

3.  Pascal  allows  the  declaration  of  record  structures  which  make  the 
program  more  readable  (Ref  2). 

4. '  Pascal  supports  linked  list  (Ref  2).  Using  linked  lists  with 

FORTRAN  is  very  awkward  because  FORTRAN  does  not  support  the 
function. 

The  only  advantage  of  FORTRAN  over  Pascal  is  the  fact  that  more  of  the 
sponsor's  personnel  were  already  familiar  with  FORTRAN  than  Pascal. 
Since  the  benefits  of  using  Pascal  out-numbered  the  benefits  of  FORTRAN, 
Pascal  was  chosen  as  the  programming  language  of  CGS. 

Summary 

To  summarize,  this  chapter  has  been  devoted  to  discussing  the  CGS 


software  requirements  and  selecting  a  programming  language  for  CGS.  A 
brief  summary  of  the  software  requirements  are  as  follows: 


1.  The  operator  interface  must  be  friendly,  clear,  and  forgiving.  It 
must  lead  the  inexperienced  user  "by  the  hand"  with  descriptive 
promps,  and  provide  a  very  short  command  language  for  the 
experienced  user.  It  must  also  provide  help  to  the  users  when 
necessary. 

2.  The  Parameter  capability  requires  the  following  functions  to  be 

performed: 

(a)  The  different  regions  in  the  user's  display  must  be  protected 

from  each  other, 

(b)  The  static  regions  of  the  Parameter  display  have  to  hg  drawn. 

(c)  The  data  taken  from  the  OFP  by  the  hardware  monitor  have  to  be 
decoded. 

(d )  The  dynamic  regions  of  the  Parameter  display  have  to  be  created 
and  maintained. 

3.  The  RWR  capability  requires  several  different  functions  to  be 

performed: 

(a)  The  different  regions  in  the  user's  display  must  be  protected 

from  each  other. 

(b)  The  static  regions  of  the  RWR  display  have  to  be  drawn. 

(c)  The  data  taken  from  the  OFP  by  the  hardware  monitor  must  be 
decoded. 

(d)  The  dynamic  regions  of  the  RWR  display  must  be  created  and 
maintained. 

This  chapter  completes  the  definition  of  the  ALR-46  CGS  requirements. 

The  transformation  of  the  CGS  system  requirements  into  an  operational 

system  is  discussed  in  Chapter  IV. 
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The  previous  chapter  employed  the  user  survey  to  determine  the 


software  system  requirements.  In  this  chapter,  the  software 
requirements  along  with  supporting  background  information  were  used  to 
design  CGS.  In  the  first  phase.  Structured  Analysis  (Ref  8)  was 
employed  to  build  a  logical  model  of  CGS.  Transform  and  Transaction 
Analysis  techniques  (Ref  17)  were  used  in  the  final  phase  of  the  design 
to  convert  the  logical  model  into  a  physical  model.  The  module 
structure  charts  created  by  the  transform  and  transaction  analysis 
process,  are  found  in  Appendix  D. 

Loxical  Model 

Introduction.  While  the  software  requirements  were  discussed  in 
Chapter  III,  further  analysis  could  prevent  errors  from  being  designed 
into  CGS.  Several  techniques  were  available  for  this  task  including 
Weinberg's  Structured  Analysis  (Ref  8),  Softech's  Structured  Analysis 
and  Design  Technique  (SADT)(Ref  16),  and  IBM's  Hierarchical 
Input-Process-Output  (HIPO)  diagrams  (Ref  8).  Structured  Analysis  was 
selected  to  build  the  logical  model  because  it  offers  several 
advantages.  However,  before  the  advantages  can  be  discussed,  it  is 
necessary  to  understand  the  basic  components  of  the  Structured  Analysis 
technique . 


Data  Flow 
Name 


Data  Flow 


Figure  18.  DFD  Components 


Structured  Analysis  uses  data  flow  diagrams  (DFD's)  and  a  data 
dictionary  to  logically  define  the  system  requirements.  The  DFD's  have 
the  four  components  shown  in  Figure  18.  The  first  component  is  the  data 
flow,  a  "pipeline"*  of  other  data  flows  and  of  data  elements.  The  data 
elements  are  basic  data  types  that  can  not  be  partitioned  further  and 
still  retain  their  meaning.  For  example,  the  data  element  might  be  an 
integer  word  representing  the  number  of  active  threats  at  a  specific 
instant  in  time.  The  data  flow  is  represented  by  a  curved  arrow  on  the 
DFD's.  The  process  converts  input  data  flows  to  output  flows  and  is  the 
second  component  of  the  DFD's.  It  is  represented  by  a  circle  that 
contains  the  process  name.  The  box  represents  the  third  component  of 
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DFD's,  the  sources  and  sinks  of  information.  They  may  represent  a  user 
keyboard,  a  user  display,  or  any  other  mechanism  by  which  information 
enters  or  leaves  the  system.  Finally,  files  are  the  last  component  and 
are  repositories  of  information  within  the  system.  They  are  shown  by 
straight  lines.  The  DFD's  are  layered,  starting  with  a  context  diagram 
that  defines  the  interface  of  the  system  with  its  environment.  Then  the 
processes  in  the  diagram  are  expanded  into  lower  level  DFD's.  This 
partitioning  process  continues  until  each  process  has  been  defined  in 
sufficent  detail,  or  in  terms  of  its  most  elementary  inputs  and  outputs 
(Ref  8:78). 

With  this  very  abbreviated  description  of  Structured  Analysis  ,  it 
is  now  possible  to  examine  the  three  primary  advantages  Structured 
Analysis  offered.  First,  it  was  based  on  the  concept  of  partitioning. 
This  allowed  each  CGS  requirements  to  be  analyzed  in  an  orderly  manner. 
Second,  Structured  Analysis  differentiated  between  the  logical  and  the 
physical  environment,  thus  more  clearly  defining  the  problem. 
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Figure  19.  Context  Diagram 


Finally,  it  was  fairly  easy  to  transition  from  the  DFD's  in  the  logical 
model  (Ref  Table  5)  to  the  module  structure  charts  (Ref  17)  used  in  the 
physical  model. 

Context  Diagram.  The  context  diagram  shows  the  system  boundary 
and  interface  with  the  user.  As  shown  in  Figure  19,  CGS  must  include 
everything  from  the  user  input  at  the  keyboard  to  the  response  the  user 
receives  at  the  display. 

System  Diagram.  The  system  diagram  translated  the  software 
requirements  for  CGS  into  a  logical  model  as  shown  in  Figure  20.  First, 
the  user  command  must  be  examined  to  determine  the  type  of  user  request 
(process  1).  If  it  is  a  Parameter  command,  CGS  must  activate  the 
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Hardware_Monitor_Pata 


Figure  20.  CGS  System  Diagram 


process  to  display  the  critcal  track  file  parameters  (process  2).  Both 
the  hardware  monitor  data  file  and  threat  symbol  type  file  must  be 
accessed  to  generate  the  critical  parameter  data.  If  the  user  command 
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is  an  RVR  command,  CGS  must  activate  the  process  to  simulate  the  pilot's 
display  (process  3).  Again,  both  the  hardware  monitor  data  and  the 
threat  symbol  type  files  must  be  accessed  by  the  process  to  generate  the 
RWR  data.  If  the  user  command  is  a  request  for  help,  the  appropriate 
help  information  must  be  output  to  the  user  (process  4).  Finally,  the 
response  output  from  one  of  the  three  processes  must  be  transmitted  back 
to  the  user  (process  5). 

Display  Critical  Track  File  Parameters.  The  display  parameters 
process  was  specified  in  more  detail  by  the  lower  level  DFD  shown  in 
Figure  21.  First,  a  block  of  data  (4000  words)  must  be  read  from  the 
hardware  monitor  data  files.  The  CGS  must  then  extract  an  emitter  track 
file  data  word  from  the  block  of  data  (process  2.1).  Next,  CGS  must 
update  its  threat  data  base  (process  2.2).  In  the  final  step,  CGS  must 
extract  the  updated  parameters  from  the  treat  data  base  and  prepare  them 
for  output  to  the  user  device  (process  2.3). 

Update  CGS's  Track  File  Entry.  The  update  track  file  entry 
process  may  be  specified  further  by  the  lower  level  DFD  shown  in  Figure 
22.  First,  the  specific  threat  being  updated  must  be  indentified 
(process  2.2.1).  This  can  be  done  using  the  address  of  the  data  words 
(Ref  figure  17).  After  the  threat  has  been  identified,  CGS  must 
identify  which  of  the  sixteen  possible  word  (Ref  Appendix  B)  has  been 
modified  (process  2.2.2).  Finally,  the  critical  parameters  affected  by 
the  change  must  be  updated  (process  2.2.3).  As  shown  in  Appendix  A, 
several  critical  parameters  can  be  affected  when  only  one  track  file 
word  is  changed. 
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Simulate  Pilots  Display.  The  simulate  pilot's  display  process 
was  specified  in  more  detail  by  the  DFD  shown  in  Figure  23.  First,  a 
block  of  data  (4000  words)  must  be  read  from  the  hardware  monitor  data 
file.  The  CGS  must  then  extract  an  emitter  track  file  data  word  from 
the  block  of  data  (process  3.1).  Next,  CGS  must  update  its  threat  data 
base  (process  3.2).  (Both  the  extract  data  word  (process  3.1)  and  the 
update  track  file  entry  (process  3.2)  processes  are  identical  to 
processes  1.1  and  2.2  shown  in  Figure  21.)  Finally,  CGS  must  extract  the 
updated  parameters  from  the  threat  data  base  and  prepare  them  for  output 
to  the  user  device  (process  3.3). 

Extract  /  Format  RWR  Data.  The  extract  /  format  RWR  data  process 
was  specified  in  more  detail  by  the  DFD  shown  in  Figure  24.  First,  the 
position  of  the  threat  symbol  must  be  determined  (process  3.3.1).  The 
position  of  the  symbol  is  a  function  of  the  threat's  range  and  azimuth. 
Next,  the  symbol  must  be  removed  from  its  current  position  on  the 
display  and  displayed  in  its  new  position  (process  3.3.2).  The  critical 
parameters  on  the  user's  display  must  also  be  updated  (process  3.3.3). 
The  threat's  symbol,  range,  and  azimuth  are  displayed  alongside  the 
simulation  of  the  pilot's  display.  Finally,  the  RWR  data  is  prepared 
for  output  by  adding  display  position  commands  (process  3.3.4). 

Help-User .  Finally,  the  help-user  process  may  be  specified  by 
the  lower  level  DFD  shown  in  Figure  25.  The  help  request  must  be 
classified  as  either  a  general  information  request,  an  RWR  display 
procedure  request,  or  a  Parameter  display  procedure  request  (process 
4.1).  If  it  is  a  general  information  request,  a  menu  selection  of  the 
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Figure  24.  Extract  /  Format  RWR  Data  (3.3)  DFD 


Figure  25.  Help  User  (4.0)  DFD 


available  commands  and  their  formats  must  be  output  along  with  the 
formats  of  the  more  specific  help  requests  (process  4.2).  If  the  help 
request  is  a  RWR  display  procedure  request,  the  format  for  initiating 
the  RWR  procedure  must  be  output  (process  4.3).  Finally,  if  the  help 
request  is  a  parameter  display  procedure  request,  the  format  for 
initiating  the  parameter  procedure  must  be  output  (process  4.4). 
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The  next  phase  in  the  design  was  to  translate  the  logical  model  of 
CGS  into  a  physical  model.  This  process  is  described  in  the  following 
section. 

Physical  Model 

Introduction.  The  physical  model  was  designed  using  structured 
design  techniques  proposed  by  Yourdon  and  Constantine  (Ref  17).  Two 
principal  methods  were  used  to  translate  the  structured  specification 
into  module  structure  charts,  transform  analysis  and  transaction 
analysis.  These  techniques  were  chosen  due  to  their  direct 
correspondence  to  the  DFD's  specified  in  the  previous  section. 

Transform  analysis  is  used  to  translate  a  DFD  into  three  sets  of 
modules.  The  first  set  of  modules  gets  data  from  the  source.  The  data 
is  transformed  into  the  output  by  the  second  set,  and  the  third  set 
outputs  the  data  to  the  sink.  To  partition  the  DFD  into  the  three  sets 
of  modules,  the  DFD  is  divided  into  an  afferent  branch,  a  transform 
section,  and  an  efferent  branch.  This  is  done  by  tracing  the  input  from 
the  source  to  the  furthest  data  flow  where  it  is  still  recognizable  as 
an  input.  Likewise,  the  output  is  traced  backwards  from  the  sink  to  the 
first  data  flow  where  it  is  recognizable  as  an  output.  These  two  data 
flows  then  are  used  as  the  boundaries  between  the  three  sections  of  the 
DFD. 

For  the  first  set  of  modules,  the  structure  is  derived  by  making  an 
afferent  module  for  each  data  flow  and  a  transform  for  each  process. 
This  is  illustrated  in  Figure  26.  For  the  second  set  of  modules,  the 
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Figure  26 


Factoring  the  Afferent  Section 


first  module  is  factored  into  subordinate  transform  modules  that  perform 
the  functions  stated  by  the  process  names.  An  example  of  this  is  shown 
in  Figure  27.  The  structure  for  the  last  set  of  modules  is  designed 
similarly  to  the  set  of  afferent  modules.  As  shown  in  Figure  28,  the 
efferent  module  has  subordinate  to  it  another  efferent  module  and  a 
transform  module  that  relates  the  two  data  flows  specified  by  the 
efferent  modules.  A  complete  description  of  transform  analysis  is  given 


Figure  27 


Factoring  the  Transform  Section 
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Figure  29.  Simulate  Pilot's  Display  Module  Structure  Chart 
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Figure  30.  Transaction  Analysis  Technique 
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Figure  31.  Help  User  Module  Structure  Chart 


in  Yourdon  and  Constantine’s  book*  Structured  Design  (Ref  17:171-201). 
This  technique  was  used  throughout  the  nodule  structure  design  phase. 
An  example  of  this  technique  being  used  in  the  CGS  design  is  shown  in 
Figure  29  for  the  simulation  of  the  pilot's  display. 

The  other  technique  used  a  great  deal  was  transaction  analysis  (Ref 
17:202-222).  This  technique  is  particularly  useful  for  translating 
DFD'8  with  processes  that  classify  an  input  as  one  of  a  number  of 
outputs.  Using  transaction  analysis,  a  DFD  like  that  shown  in  Figure 
30(a)  may  be  translated  into  a  module  structure  chart  like  that  in 
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Figure  30(b).  The  module  structure  chart  for  the  help-user  command  is 
shown  in  Figure  31  as  an  example  of  this  technique. 

Suaaacy 

This  chapter  translated  the  software  requirements  into  logical  and 
physical  models  of  CGS.  The  logical  model  used  data  flow  diagrams  to 
emphasize  the  flow  of  data  through  CGS,  while  de-emphasizing  procedural 
aspects  of  the  problem  and  physical  solutions.  The  physical  model  of 
CGS  was  derived  primarily  using  transform  and  transaction  analysis. 
These  techniques  are  briefly  described  and  the  module  structure  charts 
are  included  in  Appendix  D.  The  module  structure  charts  were  used 
during  the  implementation  of  CGS,  described  in  Chapter  V. 
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The  entire  Computer  Graphics  System  has  been  implemented.  The 
unique  factors  which  impacted  this  implementation  are  discussed  in  this 
chapter*  as  are  the  basic  principles  used  in  implementing  the  modules. 
Also,  the  test  plan  and  procedures  employed  to  verify  the  CGS  modules 
and  validate  the  system  are  described.  Finally,  the  testing  results  are 
stated. 

Implementation 

One  of  the  first  challenges  in  the  implementation  phase  was  to 
select  a  system  implementation  strategy. 

Strategy  Two  implementation  strategies  were  considered.  Top-down 
and  Bottom-up,  The  Top-down  strategy  was  chosen  to  implement  CGS  due  to 
several  advantages  it  offered.  However,  before  these  advantages  can  be 
understood,  it  is  necessary  to  understand  the  basic  concepts  in  each 
strategy. 

Top-down  design  is  a  modular  design  strategy  that  creates  a  system 
design  in  terms  of  major  functions,  which  are  decomposed  into  more 
detailed  functions.  The  top-down  implementation  suggests  that 


high-level  modules  should  be  coded  and  tested  first,  followed  by  the 
next  lower-level  until  all  of  the  modules  have  been  implemented 
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Top-Down  Implementation 


(Ref  figure  32).  High-level  modules  are  tested  using  stubs  to  simulate 
the  work  of  lower-level  modules  (Ref  8:216).  Bottom-up  design  creates  a 
system  design  in  terms  of  minor  functions,  which  are  integrated  together 
to  form  major  functions.  The  bottom-up  implementation  suggests 
low-level  modules  should  be  coded  and  tested  first,  followed  by  the  next 
higuer-level  until  all  of  the  modules  have  been  implemented  (Ref  figure 
33).  The  lower- level  modules  are  tested  using  driver  programs  and 
specialized  test  data. 

With  these  very  abbreviated  description  of  top-down  and  bottom-up 
strategies,  it  is  now  possible  to  examine  the  seven  advantages  of 
top-down  implementation  (Ref  17:340-358). 

1.  Unit,  integration,  and  systems  testing  are  all  eliminated  as 
separate  phases,  in  effect,  every  time  a  new  module  (or  small  group 
of  modules)  is  added  to  the  system,  an  integration  test  is  run.  The 
addition  of  the  last  module  in  actuality  represents  the  final  system 
test . 

2.  Major  interfaces  in  the  system  are  tested  early  with  a  top-down, 
incremental  testing  strategy.  Hierarchical  modular  designs  identify 
high-level  modular  functions  which  can  be  coded  and  tested  before 
detailed  specifications  have  been  developed  for  lower-level, 
detailed  functions.  As  a  result,  high-level  program  functions  and 
inter-program  system's  functions  can  be  tested  early,  minimizing  the 
likelihood  of  interface  problems  necessitating  revision  of 
lower-level  modules. 
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3.  Users  can  see  a  working  demonstration  of  a  skeleton  version  of  the 
system  long  before  the  entire  system  has  been  completed,  thereby 


enhancing  users'  support  for  and  involvement  with  the  system. 

4.  Deadline  problems  are  more  manageable.  Serious  design  flaws  are 
exposed  early  in  testing. 

5.  Debugging  is  easier.  In  a  bottom-up,  phased-testing  environment, 

modules  that  have  been  successfully  unit-tested  are  thrown  together 
for  an  integration  test.  If  the  test  fails,  the  bug  could  be 
anywhere  in  the  system,  causing  considerable  difficulty  in 

debugging.  With  incremental  testing  in  a  top-down  environment,  a 
module  or  small  group  of  modules  is  added  to  a  working  skeleton  of 
the  system.  If  the  test  fails  in  this  case,  debugging  probably 
would  be  reasonably  simple,  because  the  bug  would  exist  either  in 
the  newly  added  code  or  in  the  interface  between  the  new  code  and 
the  already  tested,  working  skeleton  of  the  system. 

6.  The  need  for  test  hame°ses  is  eliminated.  In  a  bottom-up 
environment,  testing  lc.-  level  modules  requires  driver  programs  and 
specialized  test  data;  the  actual  logic  of  high-level  modules,  in  a 
top-down  environment,  drives  lower- level  modules.  Module  stubs 
simulate  the  work  of  even  lower-level  modules.  Thus,  no  driver 
program  or  specialized  test  data  is  created  only  to  be  discarded 
later. 

7.  Requirements  for  machine  time  are  distributed  more  evenly  and  are 
more  predictable.  In  bottom-up  implementation,  testing  begins 
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perhaps  halfway  through  a  project  and  grows  slowly  as  modules  are 
compiled  and  unit-tested.  In  top-down  implementation,  testing 
begins  sooner  than  in  the  bottom-up  approach.  The  amount  of  daily 
test-time  increases  rapidly  early  in  a  project  and  then  increases 
gradually  as  modules  are  added  incrementally  to  the  system. 

With  the  implementation  strategy  defined,  the  next  step  was  to  transform 
the  structure  charts  described  in  Chapter  IV  into  a  format  easier  to 
implement.  The  Warnier-Orr  diagram  technique  was  chosen  because  it  is 
simple,  readable,  and  easy  to  implement.  It  proceeds  with  one  step 
leading  directly  and  logically  to  the  next  step. 

The  process  stops  when  the  last  program  hierarchial  level  defines 
one  specific  function  or  when  the  last  level  of  structure  defines  a 
unique  element  which  cannot  be  further  divided.  These  criteria  are 
readily  identifiable. 

Readability  is  of  utmost  importance  to  every  activity  following  the 
design  phase  of  software  development.  The  design  must  be  readable  and 
understandable  to  those  whose  jobs  will  be  to  code,  test  and  maintain 
the  software. 

The  last  advantage  and  one  of  the  most  important,  practically,  is 
the  ease  with  which  a  Warnier-Orr  design  can  be  implemented.  The  format 
of  the  Warnier-Orr  diagram  graphically  represents  the  three  constructs 
which  are  necessary  and  sufficient  for  any  program  implementation  : 
sequence,  decision  cud  iteration  (looping). 
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Table  6. 


List  of  all  Warnier-Orr  Diagrams 


ALR46CGS 

OPERATOR.INTERFACE 
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PARAMETER 

CREATE.TRACK.FILE.ENTRIES 

INITIAL IZ  E.TRACK.FILE.ENTRY 
READ.SYMBOL.TYPE.FILE 
SET_STATE_OF_VTl 00 

positionIcdrsor 

GENERATE_FORM 
UPDATE.TRACK.FILE.ENTRY 
PROCES  S_ONE_WORD 
SHIFT 

ALR46  .DEGREES 
OUTPUT.CRITICAL.PARA  METERS 
POSTION.CURSOR 

RWR.DI SPLAY 

CREATE.TRACK.FILE.ENTRIES 

INITIAL  IZ  E_TRACK_FILE_ENTRY 
R  EAD_SYMB  OL_TYPE_F  I L  E 
INITIAL IZ EXPOSITION 
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ALR46 .DEGREES 
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DRIVE_PILOTS  .DISPLAY 
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X. COORDINATE 

Y. COORDINATE 


In  Figure  34  module  PI  consists  of  three  sequentially  (top  to 
bottom)  executed  steps  (sequence)  :  Pll,  P12  and  P13.  Module  P12 
consists  of  two  steps  :  P121  and  P122.  At  least  one  of  P121  and  P122, 
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but  not  both,  are  executed  each  time  P12  is  executed  (decision).  The 
notations  on  Pll  and  P13  in  parenthesis  indicate  how  many  times  that 
module  is  repeated  each  time  the  parent  module,  PI, 'is  executed.  In  the 
case  of  Pll  and  P13,  the  modules  will  be  executed  from  one  to  ~m~  and 
one  to  n  times,  respectively.  This  represents  looping.  The  notation 
on  PI  indicates  that  the  sequence  P11-P12-P13  will  be  executed  only 
once. 


Extensions  to  the  basic  three  constructs  are  obtained  by  combining 
them.  A  combination  of  the  loop  and  decision  constructs  produces  the 
DO-UNTIL  or  DO-WHILE  constructs  while  multiple  decisions  illustrate  the 
CASE  statement  of  the  PASCAL  language.  These  extensions  are  mentioned 
to  illustrate  the  relationships  that  the  Warnier-Orr  diagrams  exhibit  to 
implementation.  All  of  the  Warnier-Orr  diagrams  (Ref  Table  6)  developed 
for  CGS  is  contained  in  Appendix  E.  An  overview  of  CGS  is  shown  in 
Figure  35. 

Operator  Interface.  The  first  module  to  be  implemented  was  a 
top-down  design  operator  interface.  The  primary  implementation  goals 
were  to  make  it  easy  to  use  and  to  provide  the  operator  with  help  upon 
request. 

The  user  has  the  option  of  entering  either  the  full  keywords  for 
the  commands  or  only  the  first  letter  of  the  keywords.  This  keeps  a 
regular  user  of  the  system  from  being  hampered  by  long  commands,  yet 
keeps  the  novice  or  infrequent  user  from  having  to  cope  with  cryptic 
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RWR_jaode 


< 


RWR_Display 


Figure  35.  Warnier-Orr  System  Overview 
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Table  7.  Valid  Keywords 


CGS  Command  Parameters 

1 .  IELP 

2.  £WR  DISPLAY 

3.  PARAMETER  DISPLAY 


one- letter  commands  and  parameters.  The  list  of  keywords  in  the  CGS 
command  language  is  given  in  Table  7. 

The  user  "help**  protocol  was  implemented  and  can  provide  the  user 
all  information  required  to  use  CGS.  This  module  is  tier ed,  so  entry 
into  the  procedure  can  be  accomplished  by  simply  typing  “help**. 

Data  Structures  Careful  consideration  was  given  to  data 
structures  that  are  to  be  employed.  For  example,  the  tradeoffs  of  using 
a  linked  list  verses  an  array  to  store  the  information  needed  to  drive 
the  display  was  thoroughly  studied  before  the  linked  list  was  chosen. 
The  linked  list  offered  fast  access  to  each  critical  parameter  and  was 
the  same  structure  used  in  the  ALR-46  OFP.  The  linked  list  also  allowed 
the  number  of  track  file  entries  to  vary  with  the  number  of  active 
threats  and  would  on  the  average  require  less  storage  space  than  the 
array.  On  the  other  hand,  the  array  offered  direct  access  to  key 
parameters  and  was  simpler  to  implement.  Even  though  the  linked  list 
was  more  difficult  to  implement,  it  was  easier  for  the  ALR-46  personnel 
to  maintain  because  it  was  the  same  as  the  structure  used  in  the  OFP. 
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The  requirement  for  ease  of  maintenance  made  the  linked  list  more 

1 

attractive. 

Parameter  /  RWR  Processes  During  implementation,  every  attemp 
was  made  to  continue  the  practices  employed  during  the  requirements  and 
design.  As  shown  in  Figure  36  and  37,  both  processes  were  implemented 
in  a  modular,  top-down  manner.  Also  each  module  was  implemented  such 
that  it  hid  the  data  structures  and  algorithms  employed  as  much  as 
possible  from  other  modules.  One  example  of  this  was  in  the  RWR  symbol 
display  module.  This  module  was  passed  the  symbol  and  its  location  on 
the  display.  Thus,  the  subordinate  modules  did  not  require  any 
,  knowledge  of  the  actual  threat  the  symbol  represented.  The  last  phase 

I  of  impementation  for  each  module  consisted  of  debugging  the  module. 

Care  was  taken  to  insure  changes  made  in  this  phase  did  not  destroy  the 

I 

I  structure  of  the  modules  originally  implemented.  The  code  and 

Warnier-Orr  diagrams  for  these  modules  are  included  in  Appendix  E.  Once 
the  modules  were  free  of  compilation  errors,  they  were  tested  using 
stubs  and  drivers,  as  well  as  the  techniques  described  in  the  following 
section. 

Testing 

| 

j  A  top-down  approach  was  used  to  test  CGS.  Each  module  was  tested 

f 

1 

before  another  module  was  integrated  into  CGS.  Therefore,  any  problems 
encountered  were  immediately  isolated  to  the  new  module.  Two  testing 
j  strategies  were  employed,  "black-box’'  and  "white-box".  Black-box 

testing  requires  all  test  data  to  be  derived  solely  from  the 
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Figure  36.  Warnier-Orr  Diagram  of  Parameter  Process 
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Figure  37.  Warnier-Orr  Diagram  of  RWR  Process 
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specifications,  while  white-box  testing  allows  test  data  to  be  derived 
from  an  examination  of  the  program’s  logic  (and  often,  unfortunately,  at 
the  neglect  of  the  specification) (Ref,  18:9). 

White-box  testing  was  used  to  test  each  module  as  it  was  integrated 
into  CGS.  Inputs  were  chosen  to  insure  that  all  segments  of  code  were 
executed.  Also,  when  a  branch  depended  upon  a  compound  logical 
expression,  inputs  were  chosen  for  each  of  the  possible  combinations. 

Equivalence  partitioning,  a  form  of  black-box  testing,  was  also 
used.  This  procedure  entailed  partitioning  the  input  domain  of  CGS  into 
a  finite  number  of  equivalence  classes  so  one  could  reasonably  assume  a 
test  of  a  representative  value  from  each  class  was  equivalent  to  a  test 
of  any  other  value.  For  example,  the  azimuth  parameter  has  a  legal 
range  from  zero  to  two  hundred  and  fifty  nine.  The  legal  values  were 
divided  into  sixteen  equal  subranges  starting  with  zero.  Since  any 
azimuth  value  from  a  specific  subrange  was  the  same  as  any  other  value 
from  that  subrange,  only  four  values  were  needed  to  perform  this  type 
test . 


Boundary  value  analysis,  another  form  of  block-box  testing,  was 
also  used  to  test  the  modules.  The  values  at  the  borders  of  the 
equivalence  classes  were  tested  to  detect  "off  by  one"*  errors.  An 
example  of  this  technique  is  the  testing  of  the  stagger  level  parameter. 
This  parameter  has  a  legal  range  of  zero  to  seven.  To  test  the  behavior 
of  the  module  that  decoded  the  stagger  level,  stagger  level  values  of 
zero,  one,  seven,  and  eight  were  used. 


93 


1 


The  testing  was  done  incrementally.  As  a  module  was  coded  and 
debugged,  it  was  then  integrated  into  the  set  of  modules  that  had 
already  been  tested.  This  new  set  of  modules  was  then  rigorously  tested 
using  the  techniques  already  mentioned.  This  procedure  was  repeated 
until  the  test  of  the  last  module  was  actually  a  test  of  the  complete 
CGS.  This  method  worked  well  and  allowed  interface  problems  between 
modules  to  be  isolated  quickly.  Finally,  records  were  kept  of  these 
tests  to  aid  in  maintaining  the  program.  Using  these  documented 
results,  a  modification  to  CGS  can  be  verified  using  the  same  input  data 
in  addition  to  new  data  to  test  the  extensions  or  modifications  to  CGS. 
These  test  results  are  included  in  Appendix  G. 

Summary 

The  Computer  Graphics  System  was  implemented  on  the  VAX  11/780,  but 
care  was  taken  to  ensure  its  compatibility  with  the  PDP  11/34  by  only 
using  Pascal  statements  that  were  compatiable  with  both  the  VAX  11/780 
and  the  PDP  11/34.  The  operator  interface  was  implemented  to  accomodate 
both  the  novice  and  expert  user.  The  RWR  and  Parameter  modes  were 
implemented  as  defined  in  the  system  specification.  Both  information 
hiding  and  a  careful  selection  of  data  structures  were  employed  during 
the  implementation.  Finally,  the  modules  were  tested  incrementally 
using  path  analysis,  equivalence  class  testing,  and  boundary  value 
analysis . 
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VI.  Conclusions  and  Recommendations 


This  investigation,  the  development  of  the  CGS,  was  based  on  the 
requirements  provided  by  the  Electronic  Warfare  Engineering  Branch 
Laboratory.  User  interviews  were  used  to  determine  the  user 
requirements . 

User  requirements  and  the  system  contraints  were  used  to  develop 
the  CGS  system  requirements.  This  portion  of  the  investigation  was  very 
time  consuming  since  design  decisions  had  to  be  made.  Next,  the 
software  requirements  were  defined  in  more  detail. 

The  time  invested  in  the  system  requirements  proved  worthwhile 
throughout  the  investigation.  The  design  proved  to  be  straight  forward 
because  of  the  amount  of  partitioning  that  had  already  been  done. 
Structured  design  techniques  were  employed  in  the  development  of  both 
the  logical  and  physical  models  of  CGS. 

The  software  modules  were  implemented  using  structured  techniques. 
The  most  difficulty  was  encountered  in  controlling  the  DEC  VT-100  CRT 
and  the  Tektronix  4027  CRT.  Many  of  the  specialized  comands  used  had 
limited  documentation.  Each  command  was  documented  in  CGS  at  the  time 
it  was  used. 

The  testing  was  conducted  using  branch  analysis,  equivalence  class 
testing,  and  boundary  value  analysis.  The  CGS  modules  were  tested 
incrementally  which  greatly  simplified  the  overall  system  testing. 
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In  summary,  through  the  user  interviews.  Structured  Analysis 
techniques.  Structured  Design  techniques,  and  top-down  design 
techniques,  CGS  went  from  an  idea  to  a  fully  operational  system.  All  of 
the  requirements  of  the  EW  Engineering  Branch  Laboratory  were  satisfied. 
Tests  performed  with  CGS  on  AFIT's  VAX  11/780  using  simulated  data 
indicated  CGS  will  be  a  valuable  test  tool  for  the  ALR-46  personnel. 
The  sponsor  felt  that  CGS  did  meet  the  objective  of  the  investigation, 

which  was  to  reduce  the  time  required  to  modify  the  ALR-46  system.  CGS 

will  be  installed  on  the  sponsor’s  computer  in  1982. 

Recommendations 

Because  of  the  structured  approach  used  to  develop  CGS, 
enhancements  and  additional  capabilities  can  be  added  without  affecting 
the  current  capabilities.  It  is  recommended  the  following  tasks  be 
considered  by  follow-on  investigations  in  order  to  realize  the  full 
potential  of  CGS! 

1.  Provide  a  capability  to  determine  the  amount  oc  time  used  by  each 

procedure  in  the  ALR-46  Operational  Flight  Program.  As  the  threat 

environment  becomes  more  dense,  the  number  of  threats  that  must  be 
simultaneously  processed  by  the  ALR-46  increases.  The  time  required 
to  process  a  threat  must  be  reduced  if  the  system  is  to  continue 
meeting  its  response  time  requirements.  This  CGS  capability  would 
allow  the  large  users  of  CPU  time  to  be  identified  and  thus  the 
prime  candidates  for  optimization  would  also  be  identified. 
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2.  The  response  time  of  CGS  could  be  reduced  significantly  if  DEC’s 
“QIO~  system  procedure  was  used  for  I/O  instead  of  the  standard  read 
and  write  statements.  Tests  on  the  POP  11/34  indicated  a  ten  to  one 


difference  in  speed  between  a  standard  read/write  and  QIO  (Ref  11). 

3.  The  CGS  Output ^A^Symbol  procedure  should  be  enhanced  to  include 
additional  threat  symbols. 

4.  The  operator  interface  procedure  should  be  transformed  into  a 
standalone  procedure  that  sends  and  receives  messages  to  and  from 
the  remainder  of  the  CGS  procedures.  This  would  allow  the  RWR  and 
Parameter  modes  to  operate  simultaneously  and  also  give  the  operator 
control  over  CGS  at  any  point  in  time.  At  the  present  time,  the 
operator  has  to  wait  for  one  mode  to  complete  before  another  mode 
can  be  selected. 
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A  L  R  -  4  6 
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TRACK 


FILE 


This  Appendix  contains  a  description  of  the  ALR-46  emitter  track 
file  entries  used  by  CGS  to  generate  the  Parameter  and  RWR  displays. 
Actually,  the  emitter  track  file  is  not  a  file,  but  a  buffer  within  the 
ALR-46  Operational  Flight  Program.  The  track  file  is  divided  into 
sixteen  records  which  contain  sixteen  words  each.  All  records  have 
identical  formats.  The  structure  of  the  emitter  track  file  is  shown  in 
Figure  38.  Only  the  bits  used  by  CGS  are  described.  The  function  of 
most  of  the  bits  not  described  is  classified.  Word  zero  is  used  by  the 
ALR-46  to  form  the  linked  list.  This  structure  is  discussed  in  the 
description  forword  zero  which  follows. 
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Figure  38.  Record  Structure  of  the  ALR-46  Emitter  Track  File 
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The  following  is  a  description  of  the  emitter  track  file  words  used 


by  CGS: 


WORD  0: 


1. 


I  BITS  0-15 


Bits  0  -  15:  A  sixteen  bit  address  is  contained  in  bits  0-15. 
To  understand  the  function  of  this  address,  the  reader  must 
understand  how  the  emitter  track  file  is  accessed  and 
maintained.  The  OFP,  which  resides  in  the  memory  of  the  ALR-46 
Flight  Processor,  maintains  a  set  of  pointers 
(f irst_available_record  and  f irst_emitter)  which  point  to 
records  in  the  track  file  (Ref  Fig  17).  If  the 
f irst_available_record  points  to  itself,  no  records  are 
available.  If  the  f irst_emitter  pointer  points  to  itself,  no 
emitters  are  active.  As  shown  in  Figure  17,  the  records  in  the 
track  file  form  two  linked  lists,  the  "Red_Link_List”  and  the 
'*BlueJLink_List"*.  The  Red_Link_List  is  composed  of  records  of 
active  emitters,  while  the  Blue_Link_List  contains  all  of  the 
records  available  for  use.  The  f irst_emitter_pointer  is  the 
beginning  of  the  Red_Link_List .  It  points  to  the  highest 
priority  threat,  the  highest  priority  threat  points  to  the  next 
highest  priority  threat,  etc.,  until  the  lowest  priority  threat 
is  reached.  The  lowest  priority  threat  points  to  the 
first_emitter_po inter.  The  f irst_available_emitter  pointer  is 
the  beginning  of  the 
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1 

Figure  17.  ALR-46  Emitter  Track  File 


note:  The  pointer  arrangement  shown  depicts  fifteen  used  records 
(active  emitters)and  one  available  record. 
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Blue_Link_List .  It  points  to  the  first  available  record,  the 
first  available  record  points  to  the  next  available  record. 


WORD 


1. 


etc.,  until  the  last  available  record  is  reached.  The  last 
available  record  points  to  the  f irst_available_emitter  pointer. 
When  an  enemy  threat  is  recognized  by  the  ALR-46 ,  it  is  assigned 
a  record  in  the  track  file,  based  on  the  threat's  priority.  The 
pointers  have  to  be  updated  in  both  linked  lists,  since  an 
available  record  has  to  be  removed  from  the  ”Blue_Link_List“  and 
inserted  into  the  **Red_Link_List".  As  the  ALR-46  system 
collects  more  information  about  a  threat  (PRI,  PW ,  etc.),  the 
OFP  updates  the  appropriate  vord(s)  in  the  record  associated 
with  that  threat.  Word  0  is  the  key  to  the  structure  of  the 
emitter  track  file. 


2:  I  BITS  0-15  I 


Bits  0-15:  The  sixteen  bit  address  contained  in  bits  0-15  is 
used  to  define  the  symbol  to  be  displayed.  The  address  is  an 
index  into  the  symbol  /  type  table.  Refer  to  Appendix  B  for 
additional  information. 
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WORD  3: 


BITS  0-15 


1.  Bits  0-15:  Either  the  frame  PRI  or  the  average  PRI  is  contained 
in  bits  0-15 •  If  the  pulse  train  is  staggered,  word  3  contains 
the  frame  PRI.  otherwise  it  contains  the  average  PRI.  The  units 
of  time  for  word  3  is  tenths  of  microseconds. 


WORD  4:  |  BITS  8-15  I 


1.  Bits  8-15:  The  Hi  Band  Sine  is  contained  in  bits  8-15.  It  is 
used  by  the  ALR-46  along  with  hi  band  cosine  to  determine  the 
threat's  azimuth.  The  hi  band  sine  can  range  from  zero  to  two 
hundred  and  fifty  six. 


WORD  5:  I  BITS  8  -  13 


1.  Bits  8-15:  The  hi  band  cosine  is  contained  in  bits  8-15.  It  is 
used  by  the  ALR-46  along  with  hi  band  sine  to  determine  the 
threat's  azimuth.  The  hi  band  cosine  can  range  from  zero  to  two 
hundred  and  fifty  six.  1 


WORD  6: 


(BITS  10-15  I  BITS  5-9  (BIT  3|BIT  2|BIT  llBIT  0| 


1.  Bit  0:  If  bit  0  is  set  (equal  to  one),  a  flashing  circle  is  put 
around  the  symbol  when  it  is  displayed. 

2.  Bit  1:  If  bit  1  is  set,  a  steady  circle  is  put  around  the 
symbol  when  it  is  displayed.  If  both  bit  0  and  bit  1  are  set, 
then  bit  0  governs. 

3.  Bit  2:  If  bit  2  is  set,  a  diamond  is  placed  around  the  symbol 
when  it  is  displayed. 

4.  Bits  5-9:  The  priority  is  contained  in  bits  5-9.  The  priority 
has  a  range  from  zero  to  thirty-two. 

5.  Bits  10-15:  The  Priority  /  Round  is  contained  in  bits  10  -  15. 

The  priority  /  round  has  a  range  from  zero  to  fifty  six. 


WORD  7:  I  (Bit  9l  iBit  4|Bit  3|Bit  2lBit  llBit  0| 


1.  Bit  0:  If  bit  0  is  set,  the  ALR-46  has  identified  a  threat 

whose  frequency  is  in  band  zero. 

2.  Bit  1:  If  bit  1  is  set,  the  ALR-46  has  identified  a  threat 

whose  frequency  is  in  band  one. 
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3.  Bit  2:  If  bit  2  is  set,  the  ALR-46  has  identified  a  threat 


whose  frequency  is  in  band  two. 

4.  Bit  3:  If  bit  3  is  set,  the  ALR-46  has  identified  a  threat 

whose  frequency  is  in  band  three. 

5.  Bit  4:  If  bit  4  is  set,  the  ALR-46  b  identified  a  threat 

whose  frequency  is  in  band  four. 

6.  Bit  9:  If  bit  9  is  set,  the  pulse  train  is  jittered. 


WORD  8:  I  BITS  11-15  IBITS  8-10  |BITS  5-7  I  IBITS  0-2 1 


1.  Bits  0-2:  The  Conditional  Emitter  Program  Count  (CEPC)  is 
contained  in  bits  0-2.  The  CEPC  has  a  range  from  zero  to  seven. 

2.  Bits  5-7:  The  ML  Age  is  contained  in  bits  5-7.  ML  \ge  has  a 

range  of  zero  to  seven. 

3.  Bits  8-10:  The  stagger  level  is  stored  in  bits  8-10.  The 

ALR-46  subtracts  one  from  the  stagger  level  count  before  storing 
it.  Therefore,  one  must  be  added  to  stagger  level  before  it  is 
displayed.  The  ALR-46  subtracts  one  from  the  stagger  level  in 
order  to  store  the  maximum  stagger  level  of  eight  into  a  three 

bit  field.  The  stagger  level  has  a  display  range  of  one  to 

eight. 
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4.  Bits  11-15:  The  low  band  age  is  contained  in  bits  11-15 


The 


low  band  age  has  a  range  from  zero  to  thirty-two. 


WORD  10:  I  {BITS  6-121  BIT  5 1 


1.  Bit  5:  Bit  5  is  the  sign  bit  for  the  value  contained  in  bits 
6-12.  If  it  is  set.  the  value  in  bits  6-12  is  a  negative  number 
in  ones’s  complement  form.  Otherwise,  the  value  in  bits  6-12  is 
a  positive  number. 

2.  Bits  6-12:  The  Y_Displacement  value  is  contained  in  bits  6-12. 
This  value  combined  with  the  X_Displacement  value  is  used  by  CGS 
to  calulate  the  threat*s  range  and  azimuth.  For  additional 
information,  refer  to  Appendix  C. 


WORD  12:  I  BITS  0-15  I 


1.  Bits  0-15:  The  mean  PRI  is  contained  in  bits  0-15.  Word  12  is 
the  same  as  word  3,  except  for  staggered  pulse  trains.  When  the 
pulse  train  is  staggered,  word  12  contains  the  Frame  PRI.  The 
unit  of  time  for  word  12  is  tenths  of  microseconds. 
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WORD  13: 


BITS  6-15 


I  BIT  1 |  I 


1 


2 


WORD 


1 


WORD 


.  Bit  1:  If  bit  one  is  set.  Special  is  equal  to  YY.  Otherwise, 
special  is  equal  to  NN. 

.  Bits  6-15:  The  value  of  Deviation  is  contained  in  bits  6-15. 


14:  I  I  BITS  3-71 


.  Bits  3-7:  The  High  Band  Age  Count  is  contained  in  bits  3-7.  It 
has  a  range  from  zero  to  thirty-two. 


15: 


I  Bits  0  -  4  I 


1.  Bits  0-4:  The  record  number  is  contained  in  bits  zero  through 
four.  The  record  number  has  a  range  from  zero  to  sixty-three. 


THE 


SYMBOL/TYPE 


FILE 


This  Appendix  contains  a  description  of  the  CGS  Symbol/Type  file. 
It  is  used  by  CGS  in  conjunction  with  word  two  of  the  emitter  track  file 
to  determine  the  threat's  symbol  and  type.  The  file,  which  is  part  of 
CGS's  input  data,  must  exist  prior  to  running  CGS.  The  file  contains 
sixty  four  sequential  records,  each  three  words  in  length.  The  actual 
data  contained  in  the  CGS  Symbol/Type  file  is  classified.  With  the 
approval  of  the  sponsor,  the  author  generated  an  unclassified  file  that 
could  be  used  to  develop  CGS. 

As  shown  in  Figure  39,  the  symbol/type  file  contains  two  symbols 
and  a  type  number  for  each  entry.  When  the  ALR-46  displays  a  threat,  it 
alternates  between  symbol  one  and  symbol  two.  Symbol  one  and  two  are 
always  the  same  for  threats  the  ALR-46  can  uniquely  identify. 
Therefore,  the  pilots  only  see  one  symbol.  Unfortunately,  certain 
threats  have  such  similar  characteristics,  the  ALR-46  can  not 
distinguish  between  them.  In  this  case,  symbol  one  and  systH  .  two  will 
not  not  be  the  same.  The  pilot  will  actually  see  two  different  symbols 
alternately  displayed  at  approximately  once  per  second.  The  CGS 
symbol/type  file  contains  entries  for  all  of  the  threats  the  ALR-46  can 
uniquely  identify,  as  well  as  entries  for  all  pairs  of  threats  that  can 
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Figure  39.  Symbol  /  Type  File  Structure 


not  be  uniquely  identified.  Each  entry  in  the  file  has  a  unique  type 
number. 

The  address  in  word  two  of  the  emitter  track  file  consists  of  the 
base  address  of  the  symbol  table  plus  the  offset  into  the  symbol  table. 
The  base  address  of  the  symbol  table  must  be  subtracted  from  word  two 
before  it  can  be  used  as  an  offset  into  the  symbol/type  file. 
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APPENDIX  C 


CGS  RANGE  and  AZIMUTH  CALCULATION 


This  Appendix  contains  a  description  of  the  process  used  to 
calculate  the  threat's  range  and  azimuth.  Certain  charateristics  of  the 
ALR-46  made  the  process  of  calculating  a  threat's  range  and  azimuth  very 
unique.  These  characteristics,  shown  in  Figure  40,  are  listed  below: 

1.  The  ALR-46  coordinate  system  is  shifted  45  degrees  in  the  clockwise 
direction. 

2.  The  X  coordinate  is  positive  in  the  left  direction  instead  of  the 
right. 

3.  The  negative  X  and  Y  coordinates  are  in  one's  complement  format. 

4.  The  reference  for  zero  degrees  is  shifted  ninety  degrees  in  the 
ALR-46  coordinate  system  as  compared  to  the  polar  coordinate  system. 

The  first  step  was  to  convert  any  negative  X  or  Y  coordinates  to  DEC's 
standard  format  for  negative  numbers.  The  range  was  easily  calculated 
using 


Range  =  Square  Root  (  X  **  2  +  Y  **2  ) 

The  calculation  the  azimuth  was  more  complicated  than  the  range 
calculation.  First,  the  azimuth  was  calculated  using  ALR-46  coordinate 
system,  and  it  was  then  translated  into  the  ALR-46  azimuth  using 
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Figure  40.  ALR-46  COORDINATE  SYSTEM 


the  values  of  X  and  Y  in  the  ALR-46  coordinate  system.  Refer  to  the 
”Proces8_0ne_Word"’  algorithm  in  the  source  listing  for  additional 
information. 


ALR-46  COORDINATES 
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MODULE 


STRUCTURE 


CHARTS 


This  Appendix  contains  the  complete  set  of  module  structure  charts 
needed  to  specify  the  design  of  the  software  for  CGS.  These  charts  were 
drawn  using  Yourdon  and  Constantine’s  structured  design  techniques  (Ref 
17)  . 


List  of  Data  Flow  Diagrams  PAGE 

System  Structure  Chart  .  115 

Display  Critical  Track  File  Parameters  .  116 

Update  CGS's  Track  File  Entry  .  117 

Simulate  Pilot's  Display  .  118 

Extract  /  Format  RWR  Data  . . 119 

Help  User . 120 
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Figure  41.  System  Structure  Chart 
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Figure  42.  Display  Critical  Track  File  Parameters  Structure  Chart 
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Figure  43.  Update  CGS's  Track  File  Entry  Structure  Chart 
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Figure  29.  Simulate  Pilot’s  Display  Module  Structure  Chart 
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Figure  31.  Help  User  Module  Structure  Chart 
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^,fnncn _ e 

CGS  Warnier-Orr  Diagrams  and  Source  Code 


This  Appendix  contains  the  CGS  Warnier-Orr  diagrams  and  the  source 
code  compiled  listings.  The  W/O  diagrams  were  used  to  develop  the 
source  code.  All  of  the  procedure  names  referenced  in  the  W/0  diagrams 
are  the  same  as  the  procedure  names  used  in  the  source  code.  A  list  is 
the  CGS  procedure  names  as  well  as  the  page  number  of  each  procedure's 
W/0  diagram  and  source  is  shown  on  page  122. 
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Figure  36.  Warnier-Orr  Diagram  of  Parameter  Process 
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Create  a  new  track  file  entry 
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Set  CRT  into  24  line  mode 
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SET_STATE_OF_VT 100  < 
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I 
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POSITION_CURSOR 


GENERATE_FORM  < 


Output  the  form  to  the  VT-100 
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ALR-46  linked  list  modified  <  Skip 

I 


UPDATE_TRACK_  < 
FILE_ENTRY 


PROCESS_ONE_WORD 


Track  file  modified  < 


ALR-46  linked  I  Update 

list  modification  <  threat 
complete  I  priority 


+ 


ALR-46  linked  I 

list  modification  <  Skip 
complete  I 


Track  file  modified  <  Skip 
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PROCESS_ONE_WORD  < 


Decode  word  number  zero 
+ 

Decode  word  number  two 
+ 

Decode  word  number  three 
+ 

Decode  word  number  four 
+ 

Decode  word  number  five 
+ 

Decode  word  number  six 
+ 

Decode  word  number  seven 
Decode  word  number  eight 

4- 

Decode  word  number  ten 

4 

Decode  word  number  twelve 
+ 

Decode  word  number  thirteen 

4 

Decode  word  number  fourteen 
+ 

Decode  word  number  fifteen 
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X  and  Y  >  0  and  Degrees  <  45  <  Update  angle 

I 

+ 

I 

X  and  Y  *  0  and  Degrees  >  45  <  Update  angle 


+ 


ALR-46J3EGREES  < 


X  and  Y  <  0  <  Update  angle 


+ 


X  <  0  and  Y  >=  0  <  Update  angle 


+ 


I 

X  >=  0  and  Y  <  0  <  Update  angle 
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I 

Change  to  ALR-46  track  file  <  Output  new  priority 

I 


Change  to  ALR-46  track  file  <  Skip 


OUTPUT. 
CRITICAL.  < 
PARAMETERS 


I  Delelete  all  entries  from 
Non_JActive_Emitters  <  the  display  for  any  threat 

I  no  longer  active 

+ 


Non .Active.Emitters  <  Skip 


I  Upate  the  diplay  of  any 

Modified  Emitters  <  active  threat  whose  parameters 
I  have  changed 

+ 


Modified  Emitters  <  Skip 
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RWR_ 

DISPLAY 


Define  background  color  and  maximum  RWR  range 

I 

Initialize  threat  position  records<  INITIALIZE_POSTION 


Create  track  file  entries  <  CREATE_TRACK_FILE_ENTRIES 


Initialize  symbol-type  records  <  READ_SYHBOL_TYPE_FILE 


< 


Set  the  state  of  the  4027 


<  SET_STATE_OF_40  27 


Read  a  block  from  hardware  monitor  file 


I  UPDATE_TRACK. 
I  FILE_ENTRIES 


Track  file  word  < 


I  Process 
I  Hardware  < 
I  Monitor 
!  File 
I  (1.E0F) 


Process 
One  < 
Word 
(l.last) 


I  OUTPUT_RWR. 
I  DISPLAY 


_  | 

Track  file  word  <  Skip 


Figure  37.  Warnier-Orr  Diagram  of  RWR  Process 
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STATE_OF_40  27  < 


Define  the  operator  interface  as  lines  27-34 

Define  the  graphics  interface  as  lines  1-26 

Erase  the  graphics  area 

Draw  the  three  RWR  range  rings 

Draw  the  cross  on  the  pilot's  display 

Clear  the  parameter  area  of  the  display 
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I  Delete  all  information  being 
Non  Active  Emitters  <  displayed  for  any  threat  no 

I  longer  active 

+ 


Non  Active  Emitters  <  Skip 

I 


0(JTPtJT_T0_  < 
RWR_DI SPLAY 


I  Update  the  display  I 

I  of  any  active  threat  I 

Modified  <  whose  range, azimuth,  < 
emitters  |  or  symbol  parameters  | 

I  have  changed  ! 


GET_NEXT_COLOR 

DRIVE_PILOTS_ 

DISPLAY 

SEND_CRITICAL_ 

PARAMETERS 


Modified  <  Skip 
emitters  | 
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t 


i 


New  threat  in  range  <  OUTPUT_A_SYMBOL 


+ 


New  threat  in  range  <  Skip 


DRIVE_PILOTS_DISPLAY  < 


Existing  !  Move  threat  I 

threat  <  symbol  to  <  ODTPUT_A_SYMBOL 

in  range  I  new  position  I 


+ 


Existing  I  Erase  threat  I 

threat  <  symbol  from  <  OUTPUT_A_SYMBOL 

in  range  I  display  I 
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1 


Set  the  color  for  the  next  symbol 


OUTPUT_A_SYMBOL  < 


Position  the  4027  graphics  cursor 


Output  the  appropriate  vector  commands 
to  draw  the  requested  symbol 
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I  Send  a  “blank” 

Parameters  being  deleted  <  line  to  the 

I  appropriate  entry 


SEND_CRITICAL_  < 
PARAMETERS 


+ 


_  I  Send  the  parameters 

Parameters  being  deleted  <  to  the  appropriate 

!  entry 
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I  Restart 

Current  color  greater  than  seven  <  the  color 

i  sequence 


GET_NEXT_COLOR  < 


+ 


_ _  I  Return 

Current  color  greater  than  seven  <  the  next 

I  higher  color 
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Generate  a  scale  factor  based  on  the  azimuth 
and  the  maximum  RWR  range 


Generate  the  X  coordinate  based  on  the 
scale  factor  and  the  maximum  number  of 
positions  from  the  origin  to  the  outside 
ring  on  the  4027 


146 


Generate  a  scale  factor  based  on  the  azimuth 
and  the  maximum  RWR  range 


INCOORDINATE  < 


Generate  the  Y  coordinate  based  on  the 
scale  factor  and  the  maximum  number  of 
positions  from  the  origin  to  the  outside 
ring  on  the  4027 
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1DEGIN 

HI.SAND.COS  J=  SHIFKDATA.8-15)} 
UF'DATED.ENTRIES  UPDATED. ENTRIES  T  [11] 
END! 
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UF  THE  ALR-46  LINKED  LIST  DATA  WORD  HAS  BEEN  CHANGED- THEN) 
IF  < MONITOR-DATA  CALR40ATA.  INDEX  f  13  >=  START. ADDRESS. OF-TRACK.FILE)  AND 

(HONITOR.DATA  TALR44.DAT A. INDEX  +  II  c=  END.ADDRESS.OF_TRACK.FILE)  THEN 

BEGIN 

{  GET  THE  EMITTER  NUMBER  > 
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VAR  NON-ACT  I VE-EHITTERS  I  TIRE-EMITTER* 
VAR  NODIFIED-EHITTERS  !  TYPE -EMITTER* 
VAR  OLD-EMITTERS  !  TYPE -EMITTER* 

VAR  ACTIVE -EMITTERS  l  TYPE-EMITTER* 

VAR  ADDRESS-STATUS  l  AUDSTATUS* 
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PROCEDURE  GET  JOT-COLOR!  VAR  SYrtBOl  !  TYPE.SYhBOU 
VAR  COLOR  :  integer; 

VAR  CURREMT-COLOF  INTEGER » 
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VAR  BACKGRDIMlCOLOR  :  INTEGER)! 
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{DISPLAY  THE  CRITICAL  PARAMETERS) 
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PROCEDURE  PARAMETER  (VAR  NQNI TOR. DATA  !  ARRAY4000J  {PROCEDURE  PARAMETER} 
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CASE  COKHAND  OF 
HELP  I  HELPUSERi 

CRITICAL  !  PARAMETER  (MOHITOR-DATAiCURRENT.EMITTER»FIRST.EMITTER»HON-ACTIVE_EMITTERSi 


C  G  S 


Data 


Dictionary 


This  Appendix  contains  a  description  of  all  of  the  constants, 
variables,  and  processes  used  in  CGS.  First,  the  symbols  used  in  the 
data  dictionary  are  defined  followed  by  the  data  dictionary  for  CGS, 
The  terms  described  in  this  data  dictionary  are  the  terms  used  in  the 
actual  CGS  software. 
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Data  Element  Definitions 


DATA  ELEMENT  NAME: 
DESCRITION: 


Active„emitters 

The  list  of  currently  active  emitters  is  contained 
in  Active^emitters . 


ALIASES : 


DATA  ELEMENT  NAME:  AAAJ) 


DESCRITION:  The  CGS  name  for  an  anti-aircraft  artillery  (aaa) 
threat  transmitting  in  band  zero. 


ALIASES: 


DATA  ELEMENT  NAME:  AAA_1 


DESCRITION:  The  CGS  name  for  an  anti-aircraft  artillery  (aaa) 
threat  transmitting  in  band  one. 


ALIASES: 


DATA  ELEMENT  NAME:  AAA_2 


DESCRITION:  The  CGS  name  for  an  anti-aircraft  artillery  (aaa' 
threat  transmitting  in  band  two. 


ALIASES: 


DATA  ELEMENT  NAME:  AAA_3 


DESCRITION:  The  CGS  name  for  an  anti-aircraft  artillery  (aaa) 
threat  transmitting  in  band  three. 


ALIASES: 
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DATA  ELEMENT  NAME:  Address_status 

DESCRITION:  Dsed  by  CGS  to  maintain  the  status  of  pointer 
changes  in  the  ALR-46  OFP.  Address_status  is 
initialized  to  "none_in_progress"  when  CGS  is 
activated.  When  the  ALR-46  changes  ti  track_file_ 
free_pointer  or  word  zero  of  any  of  CGS's  track 
file  entries,  address_status  is  set  to  in_progress. 
When  the  ALR-46  OFP  completes  the  pointer  change 
process,  CGS  sets  address_status  back  to  none_in_ 
progress. 

ALIASES: 

COMPOSITION:  Address_status  =  I  In_progress  I 

I  Completed  I 

I  None_in_progres  s  I 


AIR 

The  CGS  name  for  a  class  of  airborn  threats. 


DATA  ELEMENT  NAME:  ALR46 _free_pointer 

DESCRITION:  Contains  the  physical  address  of  the  first  free 
record  in  the  ALR-46 *s  emitter  track  file. 

ALIASES: 


DATA  ELEMENT  NAME:  ALR46_used_po inter 

DESCRITION:  Contains  the  physical  address  of  the  first  used 
record  in  the  ALR-46* s  emitter  track  file. 

ALIASES: 


DATA  ELEMENT  NAME 
DESCRITION 
ALIASES 
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DATA  ELEMENT  NAME:  Back_ground_color 

DESCRITION:  Represents  one  oi  the  possible  eight  colors  (0-7) 
available  to  the  user  of  the  Tektronix  4027  CRT.  It 
is  always  equal  to  the  number  of  the  background 
color  used  while  simulating  the  pilot's  RWR  display. 


ALIASES: 


DATA  ELEMENT  NAME:  Bar_2 

DESCRITION:  CGS's  name  for  a  special  class  of  surface  to  air 
missiles  (SAM)  called  SAM  2  bar. 

ALIASES: 


DATA  ELEMENT  NAME:  Bits_0_3 

DESCRITION:  As  described  in  appendix  A,  specific  bits  of  a  word 
in  the  emitter  track  file  affect  different 
parameters.  Specific  bits  must  be  extracted  from 
the  track  file  word  before  they  can  be  examined. 
Bits_0_3  is  used  to  store  bits  zero  through  three 
of  a  given  word. 


ALIASES : 


DATA  ELEMENT  NAME:  3its_6_12 

DESCRITION:  As  described  in  appendix  A,  specific  bits  of  a  word 
in  the  emitter  track  file  affect  different 
parameters.  Specific  bits  must  be  extracted  from 
the  track  file  word  before  they  can  be  examined. 
Bits_6_12  is  used  to  store  bits  six  through  twelve 
of  a  given  word. 


ALIASES: 


DATA  ELEMENT  NAME:  Bits_8_10 

DESCRITION:  As  described  in  appendix  A,  specific  bits  of  a  word 
in  the  emitter  track  file  affect  different 
parameters.  Specific  bits  must  be  extracted  from 
the  track  file  word  before  they  can  be  examined. 
Bits_8_10  is  used  to  store  bits  eight  through  ten 
of  a  given  word. 


ALIASES: 


DATA  ELEMENT  NAME:  Bit_l 

DESCRITION:  As  described  in  appendix  A,  specific  bits  of  a  word 
in  the  emitter  track  file  affect  different 
parameters.  Specific  bits  must  be  extracted  from 
the  track  file  word  before  they  can  be  examined. 

Bit_l  is  used  to  store  bit  one  of  a  given  word. 


ALIASES: 


DATA  ELEMENT  NAME:  Bit_5 

DESCRITION:  As  described  in  appendix  A,  specific  bits  of  a  word 
in  the  emitter  track  file  affect  different 
parameters.  Specific  bits  must  be  extracted  from 
the  track  file  word  before  they  can  be  examined. 

Bit_5  is  used  to  store  bit  five  of  a  given  word. 

ALIASES: 


i 
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DATA  ELEMENT  NAME:  Bit_9 

DESCRITION:  As  described  in  appendix  A,  specific  bits  of  a  word 
in  the  emitter  track  file  affect  different 
parameters.  Specific  bits  must  be  extracted  from 
the  track  file  word  before  they  can  be  examined. 

Bit_9  is  used  to  store  bit  nine  of  a  given  word. 


ALIASES: 


DATA  ELEMENT  NAME:  Blink_circle 

DESCRITION:  The  ALR-46  emphasizes  certain  symbols  on  the 
pilot’s  by  placing  a  blinking  circle  around  the 
threat* 8  symbol.  CGS  uses  Blink_circle  to  indicate 
the  threat's  symbol  should  have  a  blinking  circle 
placed  around  it. 


ALIASES: 


DATA  ELEMENT  NAME:  Completed 

DESCRITION:  Used  by  CGS  to  indicate  the  ALR-46  has  completed 
the  address  changes  associated  with  the  track  file. 
Each  time  the  ALR-46  adds  a  threat,  deletes  a 
threat,  or  changes  a  threat's  priority,  and  address 
change  occurs. 

ALIASES: 


DATA  ELEMENT  NAME:  Crot 


DESCRITION:  The  CGS  name  used  for  the  crotale  threat. 


ALIASES: 
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DATA  ELEMENT  NAME:  Current_color 

DESCRITION:  Contains  the  number  of  the  color  that  will  be  used 
to  display  the  next  threat  symbol.  The  value  of 
current_color  has  a  range  from  zero  to  seven. 

ALIASES: 


DATA  ELEMENT  NAME:  Current_emitter 

DESCRITION:  Used  to  point  to  the  Track_f ile_entry  in  CGS  that 
it  is  currently  examining. 

ALIASES: 

Note:  Refer  to  “track_f ile_entry"  for  the  composition 
of  the  records  pointed  to  by  Current_emitter. 


DATA  FLOW  NAME:  Current_threat 

DESCRITION:  Used  to  point  to  the  RWR_display_data  in  CGS  that 
it  uses  to  maintain  the  information  it  needs  to 
drive  the  RWR  display. 

ALIASES: 

COMPOSITION:  Current_threat  =  azimuth  +  color  +  new_x_position 
new_y_position  +  old_x_position  +  old_y_position  + 
range  +  status  +  symbol 


DATA  ELEMENT  NAME:  Data 

DESCRITION:  Contains  one  sixteen  bit  word  from  the  hardware. 
monitor_data  file. 

ALIASES: 
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DATA  ELEMENT  NAME:  Degrees 


DESCRITION:  Used  to  store  the  intermediate  values  of  degrees 
during  the  calculation  of  azimuth. 

ALIASES: 


DATA  ELEMENT  NAME:  Degree_to^radian 

DESCRITION:  A  constant  that  contains  the  value  to  conver 
degrees  to  radians. 

ALIASES : 


DATA  ELEMENT  NAME:  Diamond 

DESCRITION:  Used  by  CGS  to  indicate  a  diamond  should  be  placed 
around  the  emitter  when  it  is  displayed. 

ALIASES: 


DATA  ELEMENT  NAME:  Dot 

DESCRITION:  Used  by  CGS  to  indicate  a  dot  should  be  placed 
inside  the  emitter  symbol.  The  number  of  dots 
which  band  the  threat  is  transmitting  in. 


ALIASES : 


DATA  ELEMENT  NAME:  Emitter_count 

DESCRITION:  Used  by  CGS  during  the  initialization  of  the  track. 

file_entries  to  store  a  different  emitter  number  in 
each  record. 

ALIASES: 


DATA  ELEMENT  NAME:  Emitter_address 

DESCRITION:  Contains  the  address  of  the  hardware_jnonitor  word 
being  examined. 

ALIASES: 


DATA  ELEMENT  NAME:  Emitter_number 

DESCRITION:  Contains  the  number  of  the  emitter  currently  being 
processed  by  CGS. 

ALIASES: 


DATA  FLOW  NAME:  Emitter_positions 

DESCRITION:  Contains  all  fo  the  information  needed  by  CGS  to 
maintain  and  display  up  to  sixteen  threat  symbols 
on  the  RWR  display. 

ALIASES: 

COMPOSITION:  Emit ter_po sit ions  =  current_threat  +  current_threat 
+  current_threat  +  current_threat  +  current_threat 
+  current_threat  +  current_threat  +  current_threat 
+  current_threat  +  current_threat  +  current_threat 
+  current_threat  +  current_threat  +  current_threat 
+  current  threat  +  current  threat 


DATA  ELEMENT  NAME:  Emitter_priority 


DESCRITION:  Contains  a  list  of  the  active  emitter  sorted  by 

priority  starting  with  the  highest  priority  threat. 
Each  time  a  new  threat  is  recognized  or  an  existing 
threat  is  deactivated,  the  emitter_priority  is 
re-sorted. 

ALIASES: 


DATA  ELEMENT  NAME:  Ending  address  of  track  file 

DESCRITION:  Contains  the  address  of  the  last  word  in  the  ALR-46 
OFP's  track  file. 

ALIASES: 


DATA  ELEMENT  NAME:  Entry_number 

DESCRITION:  Used  by  CGS  in  the  RWR  display  to  indentify  the 
specific  entry  on  the  display  being  updated. 

ALIASES: 


DATA  ELEMENT  NAME:  ESC 

DESCRITION:  An  ascii  control  character  used  by  the  Tektronix 
4027  CRT.  It  is  equal  to  twenty  seven. 

ALIASES: 


DATA  ELEMENT  NAME:  Hawk 

DESCRITION:  Used  by  CGS  to  identify  a  specific  type  of  threat. 


ALIASES 


DATA  ELEMENT  NAME:  Hardware_jnonitor_data 


DESCR1TI0N:  The  name  used  by  CGS  to  identify  the  file  that 
contains  the  hardware  monitor  data. 

ALIASES: 


DATA  ELEMENT  NAME: 

DESCRITION: 

ALIASES: 


Index 

Used  by  CGS  as  an  index  into  the  ”emitter_priority" 


DATA  ELEMENT  NAME: 

DESCRITION: 


Input 

The  name  of  the  default  input  device  for  CGS. 


ALIASES: 


DATA  ELEMENT  NAME:  In_progress 

DESCRITION:  Used  by  CGS  to  indicate  the  ALR-46  is  in  the  process 
of  adding  a  new  threat  or  deleting  an  existing  one 
from  its  list  of  active  emitters. 


ALIASES: 


DATA  ELEMENT  NAME: 
DESCRITION: 


Jit 

Used  by  CGS  to  indicate  that  the  pulse  train  of  a 
specific  threat  is  jittered. 


ALIASES: 
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DATA  ELEMENT  NAME:  Last.emitter 


DESCRITION:  Is  set  true  to  indicate  that  all  of  the  emitters 
have  been  processed. 

ALIASES: 


DATA  FLOW  NAME:  List_of_legal_commands 

DESCRITION:  Contains  a  list  of  the  legal  CGS  commands. 
ALIASES: 

COMPOSITION:  List_of_legal_commands  =  Help  +  Critical  +  RWR 
+  Terminate 


DATA  ELEMENT  NAME:  Maximun_value_of_a_byte 

DESCRITION:  The  maximum  value  for  a  byte  is  contained  in 

maximum_value_of_a_byte.  It  is  equal  to  octal  one 
hundred  and  seventy  seven. 

ALIASES: 


DATA  ELEMENT  NAME:  Maximum_number_of_emitters 

DESCRITION:  Is  a  constant,  which  contains  the  maximum  number  of 
emitters  the  ALR-46  can  process.  It  is  initialized 
to  sixteen. 


ALIASES: 


i 

i 


DATA  ELEMENT  NAME:  Maximum_RWR_range 

DESCRITION:  Contains  the  maximum  range  that  can  be  displayed  in 
the  RWR  mode. 

ALIASES: 


DATA  ELEMENT  NAME:  Modif ied_emitters 

DESCRITION:  Conatins  a  list  of  the  threats  that  have  been 

modified  by  CGS  during  the  last  time  sequence.  The 
list  can  range  from  zero  to  sixteen. 


ALIASES: 


DATA  ELEMENT  NAME:  Monitor_data 

DESCRITION:  A  CGS  buffer  used  to  receive  a  block  of  data  from 
the  hardware  monitor  file. 

ALIASES: 


DATA  ELEMENT  NAME:  Moni‘.or_data_index 

DESCRITION:  Used  is  an  index  into  the  monitor_data 
ALIASES: 


DATA  ELEMENT  NAME:  Name 

DESCRITION:  Used  by  CGS  during  the  Parameter  mode  to  display 
the  name  of  the  critical  parameter  being  displayed. 

ALIASES: 
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DATA  ELEMENT  NAME:  None_in_progres 8 

DESCRITION:  Used  by  CGS  to  indicate  the  ALR-46  is  not  in  the 
process  of  adding  a  new  threat  or  deleting  an 
existing  threat  from  it's  list  of  active  emitters. 


ALIASES : 


DATA  ELEMENT  NAME:  Non_active_emitters 

DESCRITION:  Contain::  a  list  of  the  emitters  that  become  in 
active  during  the  last  ALR-46  time  sequence.  The 
list  can  range  from  zero  to  sixteen. 


ALIASES: 


DATA  ELEMENT  NAME:  No_highlighter 

DESCRITION:  Used  by  CGS  to  indicate  whether  or  not  the  emitter 
being  displayed  has  a  highlighter 

ALIASES: 


DATA  ELEMENT  NAME:  Old_emitterS 

DESCRITION:  Contains  a  list  of  threats  that  were  active  during 
the  last  sequence. 

ALIASES: 


DATA  ELEMENT  NAME: 

DESCRITION: 


Out_of_range 

Used  by  CGS  to  indicate  a  threat  is  outside  the 
legal  display  range. 


ALIASES: 
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DATA  ELEMENT  NAME:  PC_flag 


DESCRITION:  Used  to  identify  the  type  of  hardware  monitor  data 
being  examined.  It  is  equal  to  octal  177777.  Refer 
to  table  4  for  data  format. 


ALIASES: 


DATA  ELEMENT  NAME:  PI 


DESCRITION:  A  constant  equal  to  3.14159. 


ALIASES: 


DATA  ELEMENT  NAME:  Randians_to_degrees 

DESCRITION:  A  CGS  constant  used  to  convert  radians  to  degrees. 
ALIASES: 


DATA  ELEMENT  NAME:  SA_1 

DESCRITION:  The  symbol  used  by  CGS  to  identify  a  type  one 
surface  to  air  missile  (SAM)  site. 

ALIASES: 


DATA  ELEMENT  NAME:  SA_2 

DESCRITION:  The  symbol  used  by  CGS  to  identify  a  type  two 
surface  to  air  missile  site. 

ALIASES: 


1 


DATA  ELEMENT  NAME:  SA_3 

DESCRITION:  The  symbol  used  by  CGS  to  identify  a  type  three 
surface  to  air  missile  site. 

ALIASES: 


DATA  ELEMENT  NAME:  SA_4 

DESCRITION:  The  symbol  used  by  CGS  to  identify  a  type  four 
surface  to  air  missile  site. 

ALIASES: 


DATA  ELEMENT  NAME:  SA_5 

DESCRITION:  The  symbol  used  by  CGS  to  identify  a  type  five 
surface  to  air  missile  site. 

ALIASES: 


DATA  ELEMENT  NAME:  SA_6 

DESCRITION:  The  symbol  used  by  CGS  to  identify  a  type  six 
surface  to  air  missile  site. 

ALIASES: 


DATA  ELEMENT  NAME:  SA_7 

DESCRITION:  The  symbol  used  by  CGS  to  identify  a  type  seven 
surface  to  air  missile  site. 

ALIASES: 
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DATA  ELEMENT  NAME:  SA_8 

DESCRITION:  The  symbol  used  by  CGS  to  identify  a  type  eight 
surface  to  air  missile  site. 

ALIASES: 

DATA  ELEMENT  NAME:  SA_9 

DESCRITION:  The  symbol  used  by  CGS  to  identify  a  type  nine 
surface  to  air  missile  site. 

ALIASES: 

DATA  ELEMENT  NAME:  Stab 

DESCRITION:  Used  by  CGS  to  indicate  the  threat's  pulse  train  is 
stable. 

ALIASES: 


DATA  ELEMENT  NAME:  Staf2 

DESCRITION:  Used  by  CGS  to  identify  a  special  type  two  surface 
to  air  missile  site. 

ALIASES: 

DATA  ELEMENT  NAME:  Staf6 

DESCRITION:  Used  by  CGS  to  identify  a  special  type  six  surface 
to  air  missile  site. 


ALIASES: 


1 


1 


DATA  ELEMENT  NAME:  Staf8 

DESCRITION:  Used  by  CGS  to  identify  a  special  type  eight  surface 
to  air  missile  site. 

ALIASES: 


DATA  ELEMENT  NAME:  Stag 

DESCRITION:  Used  by  CGS  to  indicate  the  threat's  pulse  train  is 
staggered . 

ALIASES: 


DATA  ELEMENT  NAME:  Steady_circle 

DESCRITION:  Used  by  CGS  to  indicate  the  threat  symbol  should 
have  a  steady  circle  placed  around  it  as  a  high¬ 
lighter. 


ALIASES: 


DATA  FLOW  NAME:  Track_f ile_free_po inter 

DESCRITION:  Contains  the  address  used  by  the  ALR-46  to  point  to 
to  the  first  free  record  in  its  emitter  track  file. 

ALIASES: 


DATA  ELEMENT  NAME:  Track_f ile__used_po inter 

DESCRITION:  Contains  the  address  of  the  word  used  by  the  ALR-46 
to  point  to  the  first  used  record  in  its  emitter 
track  file. 


ALIASES: 
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DATA  FLOW  NAME:  Track_file  jointer 


DESCRITION:  Points  to  spcecific  entry  in  the  CGS  track  file. 

ALIASES: 

COMPOSITION:  Track_file  jointer  =  azimuth  +  cd_age_counter  + 
cepe  +  deviation  +  emitter_type  +  high_lighter  + 
hi_band_age jnt  +  hi_band_cos  +  hi_band_ain  + 
lethality_ring  +  ml_age  +  nextjmitter  +  power_ 
pwround  +  priority  +  prio  joweround  +  pri_average 
+  pri_f  rame  jeriod  +  pules_train_descriptor  + 
range  +  recordjumber  +  rf_band  +  special_f  ield  + 
stagger_level  +  symbol  +  updated_entr ies  + 
x_displacement  +  y_displacement 


DATA  ELEMENT  NAME:  Starting_address jf_track_f ile 

DESCRITION:  Contains  the  address  of  the  first  word  in  the 
ALR-46  OFP's  track  file. 

ALIASES: 


DATA  ELEMENT  NAME:  UnkO 

DESCRITION:  Used  in  CGS  as  a  label  for  a  threat  that  the  ALR-46 
is  unable  to  identify.  The  "Unknown  threat  is 
tranmitting  in  band  zero. 

ALIASES: 


DATA  ELEMENT  NAME:  Unkl 

DESCRITION:  Used  in  CGS  as  a  label  for  a  threat  that  the  ALR-46 
is  unable  to  identify.  The  "Unknown"  threat  is 
tranmitting  in  band  one. 

ALIASES: 
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DATA  ELEMENT  NAME:  Dnk2 


DESCRITION:  Used  in  CGS  as  a  label  for  a  threat  that  the  ALR-46 
is  unable  to  identify.  The  "Unknown"  threat  is 
tranmitting  in  band  two. 

ALIASES: 


DATA  ELEMENT  NAME:  Unk3 

DESCRITION:  Used  in  CGS  as  a  label  for  a  threat  that  the  ALR-46 
is  unable  to  identify.  The  "Unknown"  threat  is 
tranmitting  in  band  three. 

ALIASES: 


DATA  ELEMENT  NAME:  Unk4 

DESCRITION:  Used  in  CGS  as  a  label  for  a  threat  that  the  ALR-46 
is  unable  to  identify.  The  "Unknown"  threat  is 
tranmitting  in  band  four. 

ALIASES: 


DATA  ELEMENT  NAME:  Vertical_line_count 

DESCRITION:  Used  by  CGS  to  count  the  number  of  vertical  lines 
during  the  initialization  of  the  VT-100  CRT. 

ALIASES: 


DATA  ELEMENT  NAME:  Wing 

DESCRITION:  Used  in  CGS  to  identify  a  specific  airborn  threat 


ALIASES: 


DATA  ELEMENT  NAME:  Word_number 

DESCRITION:  Contains  the  number  of  the  word  being  examined  from 
a  CGS  track  file  entry.  It  has  a  range  from  zero  to 
f ifteen. 


ALIASES: 


DATA  ELEMENT  NAME:  X_scale_f actor 

DESCRITION:  Is  a  percent  of  the  maximum  distance,  from  the 

origin  of  the  RWR  display*  a  tnreat  can  be  placed. 
For  example,  if  x_scale_f actor  was  equal  to  one 
hundred  percent,  then  the  symbol  would  be  placed  at 
the  intersection  of  the  x  axis  and  the  outer  most 
ring. 


ALIASES: 


DATA  ELEMENT  NAME:  Y_scale_f actor 

DESCRITION:  Is  a  percent  of  the  maximum  distance,  from  the 

origin  of  the  RWR  display,  a  threat  can  be  placed. 
For  example,  if  y_scale_factor  was  equal  to  one 
hundred  percent,  then  the  symbol  would  be  placed  at 
the  intersection  of  the  y  axis  and  the  outter  most 
ring. 


ALIASES: 
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APPENDIX  G 


CGS  TEST  DOCUMENTATION 


The  data  used  to  validate  CGS  was  divided  into  two  separate  files, 
one  dedicated  to  the  validation  of  the  Parameter  mode  and  the  other 
dedicated  to  the  RWR  mode.  Two  data  bases  allowed  data  to  be  selected 
that  made  it  easy  to  visually  validate  each  mode  by  examining  the 
information  displayed  on  the  operator's  CRT.  For  example,  the  record 
number  data  values  selected  for  the  Parameter  mode  resulted  in  sixteen 
record  numbers  ranging  from  one  to  sixteen.  Both  the  Parameter  mode  and 
the  RWR  mode  data  bases  were  divided  into  groups,  one  for  each  type  of 
word  processed  by  CGS.  Each  group  can  be  easily  identified  by  the 
number  which  precedes  it.  For  example,  the  data  words  for  word  number 
two  are  preceded  by  the  number  two  entered  four  times.  The  results  of 
the  execution  of  CGS  with  the  parameter  data  base  is  shown  in  Table  8. 
The  results  of  the  execution  of  CGS  with  the  RWR  data  base  is  shown  in 
Table  9.  The  ALR-46  test  data  base  follows  Table  9. 
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Table  8.  Parameter  Display  Test  Results 


BY  PRIORITY  II  2  3 . 16 

SYMBOL  I  SA_1  ..  SA_9  HAWK  BAR_2  CROT  WING  AIR  AAA _0  AAA_1 

TYPE  I  101  102  103  104  105  .  116 

BANDS  II  2  3  4  0 . 0 

PRI  /  FRAME  PER  |  1.1  2.2  3.3  4.4  ..9.9  11.1  ....  77.7 

PULSE  TRAIN  DES  1 2STAG  3  STAG  ....  8  STAG  STAB . STAB 

PRI  AVERAGE  I  1.1  2.2  3.3  ..  .  9.9  1.1 . 7.7 

DEVIATION  I  1.0  2.0  3.0  .  16.0 

SPECIAL  I  YY  NN  YY . NN 

POWER/PWR  ROUND  |  1  2  3 . 16 

HIGH  BAND  SINE  |  1  2  3 . 16 

HIGH  BAND  COS  I  1  2  3 . 16 

CEPC  II  2  3 . 16 

HI  BAND  AGE  CNT  I  1  2  3 . 16 

CD  BAND  AGE  CNT  i  1  2  3 . 16 

PRIORITY  |1  2  3 . 16 

PRIORITY  /ROUND  |  1  2  3 . 16 

AZIMUTH  10  22  45 .  337 

LETHALITY  RING  |  0  0  0 . 0 

ML  AGE  II  2  3 . 16 

RECORD  NUMBER  I  1  2  3 . 16 


211 


Table  9.  KWR  Display  Test  Results 


SYMBOL 

RANGE 

AZIMUTH 

SA_1 

100 

0 

SA_2 

• 

• 

100 

• 

• 

22 

• 

• 

• 

• 

SA_9 

• 

• 

100 

• 

a 

180 

HAWK 

100 

202 

BAR_2 

100 

225 

CROT 

100 

247 

WING 

100 

270 

AIR 

100 

292 

AAA J) 

100 

315 

AAA_1 

100 

337 

SA_1 

100 

0 

SA_2 

100 

22 

SA_3 

100 

45 

WING 

100 

67 
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Continuation  of  Block  20 

An  ALR-46  Computer  Graphics  System  (CGS)  for  the  Electronic  Warfare 
Division  Engineering  Branch  Laboratory  was  designed  and  implemented.  The 
system  is  composed  of  the  ALR-46  Radar  Warning  Receiver;  real  time  hardware 
monitor;  PDP  11/34  computer;  and  two  display  devices,  a  Tektronix  model 
4027  CRT  and  a  Digital  Equipment  Corporation  (DEC)  model  VT-100  CRT.  The 
ALR-46  test  engineers  at  the  Engineering  Branch  laboratory  were  interviewed; 
their  functional  requirements  were  translated  into  a  detailed  set  of  hard¬ 
ware  and  software  requirements.  Structured  Analysis  Techniques  were  used 
to  produce  a  structured  specification  for  the  system  requirements.  Yourdon 
and  Constantine's  Transform  and  Transaction  Analysis  techniques  were  used 
to  develop  module  structure  charts  for  the  software  design.  The  final 
software  design  phase  translated  the  module  structure  charts  into  Warnier- 
Orr  (W/0)  diagrams.  These  were  translated  into  operational  software  using 
DEC  Pascal.  The  software  was  implemented  and  tested  using  a  top  down 
approach.  The  modules  and  data  structures  were  designed  to  allow  additional 
capabilities  to  be  added  to  CGS  with  minimum  impact  on  the  current  system. 
The  data  acquired  by  the  hardware  monitor  from  the  ALR-46  is  passed  to  the 
PDP  11/34  for  CGS  analysis.  This  information  is  used  either  to  simulate 
the  pilot's  display  or  to  generate  a  critical  parameter  display  describing 
the  threats  being  processed  by  the  ALR-46. 


UNCLASSIFIED 


SECURITY  CL  AS5I  PICATIOR  O'  Tu"' 


GE 


D 


